Re: [apps-discuss] AJAX is the new NAT

[Ted Hardie <[e-mail]>]

On Wed, Mar 23, 2011 at 1:22 PM, Carsten Bormann <[e-mail]> wrote:
> So, AJAX appears to be the new NAT.

So, that's a very good sound bite, but not a very accurate analysis.
There are two pieces that have been pointed out it a variety of ways
which you seem to miss:

 Once a node can
> control the code on *both* communicating peers, it can do interesting
> things without having to standardize much, as shown in RFC 3320 and as
> demonstrated nicely in AJAX.

The first is that AJAX is a client-server model which ensure that only
one of the two nodes can control the code on *both* communicating
peers.  That has a set of impacts that has been alluded to already in
this discussion, and it tends to concentrate power and development
effort.  You could say that enables innovation, as it creates a pool
of libraries and methods that can be re-used by others.  You could say
it stifles it, because that concentration ignores other fertile
ground.

It's that second point that is really at issue for the web as a
platform for application delivery.  Those issues don't relate as
strongly to the downloadable code issue as the base protocol having
been built for synchronous transfer of relatively small, cachable,
discrete objects; it's changed, of course, but the ability to do
reasonable things on that basis has its limits.

The RTCWeb effort that will be discussed in the upcoming BoF has been
trotted out as an example of the beauty of this approach.  In fact,
it's a great example of the tension.  Some aspects of the real-time
communication it means to enable can be mediated by web servers fairly
easily (the rendezvous and, to some extent, the negotiation).  Other
aspects, like the audio and video streams passed among peers, still
make much more sense delivered as RTP or using RTP-like flows.   (NB:
my personal opinion; the eventual WG will have to draw the lines
itself).

In other words, there is a class of client-server protocols for which
downloadable code is a good tool.  There are other protocol
requirements that are, bluntly, ill-met by that.  We want innovation
to proceed in both classes of problem. Which means enabling the first
class *while acknowledging its limits*.

Just my two cents, of course.

Ted Hardie