W3C home > Mailing lists > Public > public-web-intents@w3.org > June 2012

Re: rewrite of section 4

From: Robin Berjon <robin@berjon.com>
Date: Wed, 20 Jun 2012 18:06:05 +0200
Cc: "public-web-intents@w3.org" <public-web-intents@w3.org>
Message-Id: <DE049FBB-8E84-4261-93D9-16975F79C78B@berjon.com>
To: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>
Hi Jean-Claude

On Jun 20, 2012, at 16:19 , Jean-Claude Dufourd wrote:
> On 20/6/12 14:13 , Robin Berjon wrote:
>> From a Web architecture point of view, it has long been the accepted wisdom that how a UA is split does not matter in the least. 
> JCD: That is quite a sweeping argument.

It's meant to be.

> It sounds like it is OK to be blind to what happens inside the UA :o)

It's not just okay, it's actually a good practice. It really is no business of the specification to state whether an implementation should run over a single core or multiple, should be on a single machine or several, should use pigeons or rabbits to memorise your field entries, etc. A specification describes a black box. What happens inside the black box is SEP.

> I think I gave the argument that the way the spec is written encourages browser lock-in, if only by obfuscation.

Not any more than the myriad other information that a browser can be storing on behalf of the user. Things like bookmarks, passwords, history of course, but more importantly data in the browser's local storage. The solution isn't to invent conceptually split agents for all the relevant specifications (not to mentions things that don't have a specification at all).

One solution is to standardise a system-level API to talk to a browser's innards. That might happen in the SysApps group. Another solution (that I'd really like to see) would be to standardise a protocol for things like Firefox Sync (fka Weave). You could then just switch browsers and get all of your data back, across multiple devices (so long as they're peered).

These have the advantage of being orthogonal, of not requiring complicating all the specifications that trigger data storage of some form (not to mention having to invent new ones for parts that don't exist), and of maintaining the UA as a black box which is a better approach for conformance as well as for innovation.

> I am very uneasy with the browser having sole control over intents and how they are processed.
> I would rather have the intents processed in another (more open) layer than the browser
> Of course it make the spec a bit more complex to describe a separable process, but the extra freedom is worth the extra complexity.

Nothing in the specification prevents you from doing that already!

-- 
Robin Berjon - http://berjon.com/ - @robinberjon
Received on Wednesday, 20 June 2012 16:06:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 20 June 2012 16:06:37 GMT