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

[Scott Brim <[e-mail]>]

On Mon, Mar 21, 2011 at 12:52, Cyrus Daboo <[e-mail]> wrote:
> Hi Scott,
>
> --On March 21, 2011 12:40:01 PM -0400 Scott Brim <[e-mail]>
> wrote:
>
>>> 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.
>>
>> What interoperability do you need?  This isn't peer to peer, it's
>> client/server.  All of the servers have de facto converged on the same
>> client capabilities (http, html etc).  It's already standardized.
>
> What if I have multiple service providers yet I want to present an
> aggregated view of all the data? e.g. the very common case of having
> multiple email accounts on different providers and wanting a "unified"
> inbox. With the "proprietary" approach of silo-ed web services, that becomes
> hard. Either I have to have a local app that understands each of the
> "proprietary" protocols and does the aggregation locally, or I have to rely
> on an intermediary to aggregate the data (which probably requires handing
> over credentials or doing some complicated crypto).

First, as I understand it, the aggregator is the browser.  Don't think
of each of these as "mail".  They are more "browser-based
interactions" that might include mail.  Consider the google "mail"
front page, which can optionally have 17 other things (calendar,
online friends, grocery manager via Google API, etc.).  So if your
browser has the tools to connect to each of these services -- which it
does -- then it becomes a problem of how to show multiple "pages" in
an interesting way.

Second, if you want to totally integrate, e.g. have a common inbox for
mail, then yes you need 'mail' APIs for each of them, as opposed to
'service' APIs that I believe we're talking about.