Re: [apps-discuss] IETF technical plenary: the end of application protocols

[Scott Brim <[e-mail]>]

On Mon, Mar 21, 2011 at 10:31, Dave CROCKER <[e-mail]> wrote:
> Folks,
>
> I just saw the announcement for the Technical Plenary presentation.
>
> As described, the session suggests a failure to recognize at least two
> architectural issues.

Dave, here's my understanding ...

> One is that it mandates full-time connectivity.

No.  Look, for example, at 'offline gmail', in which browser-based
scripts cache files locally while doing their normal job of
interacting with a cloud-based service.  For starting offline, there
is a little local app that essentially says "fire up a browser and run
this script in it".

> The other is that protocols
> that it says are no longer needed are in fact still needed in some form,
> albeit
> as a layer above HTTP, rather than TCP.

On one hand you have application programs with socket interfaces
speaking to TCP and controlling everything TCP does.  On the other you
have application modules loaded by a browser and speaking to the
browser (not necessarily HTTP).

> Replacing TCP with HTTP does not eliminate the requirement for purpose-built
> application protocols, such as specialized mailbox access.

It's not replacing TCP with HTTP.  It's adding another more abstract API.

> On the other hand, it does tend to encourage an explosion of competing,
> incompatible application protocols, making for rather remarkable burdens on
> servers and clients.

Those 'clients' are installed by the services.  There is no need for
every mail-related service to use exactly the same interface, since
nothing needs to know in advance how the interaction will go.  A few
basics need to be agreed, e.g. HTTP, HTML, PHP, Javascript.  But how
those scripts actually speak to the service does not need to be
standardized.

> The summary also neglects to mention rather significant security concerns in
> all this real-time application downloading...

Please say more.