Re: [widgets] Widgets URI scheme... it's baaaack!

Marcos, Mark, all,

I am picking up the discussion where Cyril left it some months ago. I 
have read this thread, the Oct 08 one, the proposed URI scheme spec, 
even skimmed through the wam minutes. I still am leaning towards Mark's 
position. It seems to me that the URI scheme is not needed, or if 
needed, the reasons have not yet been "shown".
I am trying to reformulate the situation:

0- the author needs a way to point to resources within the widget package

1- the "URI scheme will never be used by the author" (written by 
Marcos), the author will use relative URIs for resources within the widget.

2- the browser will have to resolve the relative URI to an absolute URI 
because of the DOM spec, hence a possible vulnerability by divulging 
private information (e.g. actual name of current user in file: URI 
example of Apple Dashboard widgets) to scripts running in the widget.

3- Marcos seems to be deducing from 2- that a URI scheme must be defined 
for mandatory internal use in all widget UAs to guarantee that this 
vulnerability does not exist.

3- does not follow logically from 2-.
"Mandating the implementation in the widget UA of a URI resolution that 
does not divulge private information to the widget scripts" is 
sufficient to ensure that the vulnerability mentioned in 2- does not 
happen. The proposed URI scheme could be suggested as an option, but not 
more.

My understanding is that 3- mandates a particular URI scheme which will 
never be used by the author and will never be exchanged between two 
implementations.
My past standardization experience is that things which "will never be 
used by the author and will never be exchanged between two 
implementations" should not be standardized at all. Are there other 
predicates for the need for standardisation ?

Marcos mentions the widget V2 spec and extensibility as one reason for 
adopting the proposed URI scheme. I would like to understand how V2 and 
extensibility could make the URI scheme either seen by the author or 
exchanged between implementations, or make its absence otherwise imperil 
implementations.
Thanks.

Best regards
JC

-- 
JC Dufourd
Groupe Multimedia/Multimedia Group
Traitement du Signal et Images/Signal and Image Processing
Télécom ParisTech, 46 rue Barrault, 75 013 Paris, France

Received on Tuesday, 26 May 2009 16:15:44 UTC