Re: rewrite of section 4

Hi Robin

You response seems besides my point. I agree that a spec should leave 
the implementors free of how they work, within the constraints of 
But my point is completely different.

I claim there is a need for an additional API, because the UA cannot 
cover all use cases, specially the ones that do not conform the 
one-browser-running-on-one-device-connected-to-internet model. So the 
Web Intents Agent implemented inside the UA will cover the use cases 
appropriate for the browser vendors.
This is fine if it is possible to supersede the internal Web Intents 
Agent with an extension, a plugin, a shim, whatever.
Otherwise, Web Intents will never be picked up for use cases such as the 
ones important for the Web and TV IG.

Best regards

On 20/6/12 18:06 , Robin Berjon wrote:
> 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!

JC Dufourd
Directeur d'Etudes/Professor
Groupe Multimedia/Multimedia Group
Traitement du Signal et Images/Signal and Image Processing
Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France
Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144

Received on Monday, 16 July 2012 09:44:45 UTC