Re: [widgets] 'widget:' protocol

On 2008-05-23 09:16:01 +1000, Marcos Caceres wrote:

> The purpose is to stop implementations from using 'file://', and
> hence, addressing anything on the file system. In the config doc,
> authors are still free to use either relative or absolute
> references (but not full URIs or the widget protocol) to address
> resources inside a package. Using the widget protocol inside a
> start file will have no effect (ie. authors cannot address
> resources inside another widget).

Arve B and I were just talking in IRC about all this.

My point was that anything that leads to special-case URI references
in widgets which you can't evaluate when running the widget *from* a
file:// URI will make development a larger pain -- one of the
promises here is, after all, that you can reuse Web development
tools for widget programming.

On the other hand, just leaving relative URI references in the DOM
is simply non-starter.

So the main benefit for the widget: protocol is really that it
effectively is a way to 

 - absolutize relative URI references for DOM and possibly other
   purposes

 - without divulging the real origin to JavaScript code that's
   running

I think that's useful, and there might be usefulness to this pattern
for, say, running locally saved Web pages as well.  You don't
necessarily want to run these with a file URI, but at the same time,
you need to absolutize somehow.

The next point in the discussion was then a question around
sandboxed iframes running with globally unique origins, and
understanding the implications of location.href being unrelated to
the origin that a script runs with for the same origin policy's
purposes.  But that's a topic for more thought and another mailing
list.

> I like your "zip://" proposal:)

I don't.  I think that anything that encourages special-purpose URIs
(including either absolute or file: URIs) for widget *authoring* is
a total anti-pattern and should be called out as one.

-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Friday, 23 May 2008 12:23:00 UTC