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

[Graham Klyne <[e-mail]>]

Ah, I wish I could be there!

I think it's not so black-and-white.  The problems mentioned are real enough, 
but there are other considerations too:

- for some applications, designing to run on HTTP can increase the effective use 
of bandwidth by making it easier to build applications around more 
coarse-grained exchanges.  More bang per round-trip.  (Of course this *can* be 
done over bare TCP, but HTTP handles much of the common grunt work).

- for some applications, a focus on a RESTful style of interface pushes the 
emphasis away from multiple protocols towards a common protocol with more 
complex object representations.  Yes, this moves the application domain problems 
somewhere else, but that somewhere else is less dependent on a detailed 
bilateral agreement about the nature of exchanges.

- for some applications, using Javascript in the browser can dramatically reduce 
the complexity of a distributed client-server application, and the attendant 
network exchanges, by allowing client state to be managed locally and reducing 
the amount of state that the server needs to be aware of.

HTTP is much, much more than a simple request/response protocol.  It underpins 
the most successful, most scalable distributed application the world has seen, 
and *for some applications* that fit well into its particular model of 
interaction, I think it can offer improved efficiency and reduced siloing of 
applications.

Of course, your application may vary.

#g
--


Dave CROCKER wrote:
> 
> 
> On 3/21/2011 9:30 AM, Peter Saint-Andre wrote:
>> On 3/21/11 9:14 AM, Dave CROCKER wrote:
>>> To me, one of the more serious problems is the failure to see that these
>>> implement a potential explosion of proprietary protocols.
>>
>> This is what I see, too: each service will have its own API / protocol,
>> resulting in wonderful vendor lock-in for the service provider but a
>> distinct lack of interoperability across services. We've just moved the
>> problem elsewhere.
> 
> 
> I think Claudio raises another fundamental point, namely the loss of 
> interoperability.  The proposed model is a pure silo, with no apparent 
> ability to have variations or incremental capabilities that build on the 
> base, except by the single vendor providing the proprietary protocol.
> 
> The point that Claudio and Ted make about possible inefficiencies due to 
> repeated download is also worth noting.'
> 
> d/
>