Re: Communication Log (was: Rechartering Device APIs & Policy Working Group)

On Feb 9, 2011, at 09:07 , Bryan Sullivan wrote:
> IMO the browser is the biggest silo of all, if you want to pass out those characterizations.

Perhaps — I don't think it matters whether it is or not, or whatever its size is. If DAP designed APIs that required some browser-specific functionality, say an API that could simply not work at all if you don't have a back button, then I'd be worried (unless of course it's a history API). That would preclude that API from being used in different chrome settings and would silo it.

And that rule goes for everything. We're not in the business of creating APIs that would work only in the mobile silo, or in the app store silo, etc.

> But are you really saying that Gmail or Hotmail within the browser is an invalid use case? If not, why shouldn't access to my local folder copy as an optimization be allowed?

Bryan, if every time you quote me it's to make me say something I haven't said, it's going to be very difficult to have a productive conversation. Please by all means try to pay more attention to what I'm saying, and if I'm being unclear help me clarify.

I never said that one should not build email applications in the browser. Indeed, people have. The question isn't "should it be possible to handle mail on berjon.com?" but rather "should it be possible for berjon.com to read content from inside *your* GMail account?". I really don't see a use case for that. Or rather, I do see a small number of use cases, but they're not worth the security trade-off.

If your problem is optimisation then it's solved. IndexedDB and the File: Directories and System APIs are exactly what GMail will be using as soon as they're available in order to manage local, offline copies of your email. They don't use a CommLog API, and don't need to.

> Further, I *am* thinking more broadly of the trusted Web app domain, and not limiting the use cases to the browser implementation model. There is very significant support for the inbox read/subscribe feature inside Web apps, and the fact that so far in DAP "The working group tried hard and failed to find a way to make this work" does not mean we can't keep trying, or that once our focus extends beyond the browser, it won't get much easier (it should).

I don't understand what you mean by "beyond the browser". To me that means "that works in the browser as well as beyond". To you it seems to mean "in some specific places but definitely not in the browser". I don't see how the latter is helpful.

There are plenty of things where we can keep trying but in this case we barely have proper use cases after 18 months on the job!

-- 
Robin Berjon - http://berjon.com/

Received on Wednesday, 9 February 2011 14:03:34 UTC