Re: [apps-discuss] IETF technical plenary: the end of application 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.
>Peter
Yes, actually each service, service provider, developer-group, etc. and so
on start using own protocol/API .. the problem actually gets worse .. and
the silos get bigger and bigger (not necessarily better).

Bhumip

On Mon, Mar 21, 2011 at 12:30 PM, Peter Saint-Andre <stpeter@stpeter.im>wrote:

> On 3/21/11 9:14 AM, Dave CROCKER wrote:
> >
> > On 3/21/2011 7:43 AM, Scott Brim wrote:
> >>
>  >> On 3/21/11 8:31 AM, Dave CROCKER wrote:
> >>
> >>> 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.
> >
> > Not just an API.
> >
> > There is are a set of exchange conventions that must exist between the
> > client and the server to achieve the specifics of the application
> > service.  That the server downloads code to the client and thereby
> > provides the software for both ends of the exchange does not change the
> > fact that this is a tailored exchange.
> >
> > In networking, structured data exchanges are typically called
> protocols...
> >
> >
> >>> 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
> >
> > I was not trying to deny the operational "convenience" of this process,
> > although note that the gmail offline example still requires the user to
> > go through installation hassles.
> >
> > My point is that all this spontaneous downloading of redundant and
> > slightly different software carries some problems.  (cf, Dave Cridland's
> > response.)
> >
> > 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.
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>