Re: [widgets] Widgets URI scheme

On Thu, May 29, 2008 at 1:27 AM, Tim Berners-Lee <timbl@w3.org> wrote:
> It is important I think that the package itself have an HTTP URI.

As Arve said, there is no way to guarantee this. We are not prepared
to force authors to include an origin in order for the widget to run
(that would make them no fun, IMO).

> Yes, there will be times when you don't retrieve it in the normal course of
> business, and times when it is aggressively cached (what we call
> installation), but it should have an HTTP URI for all the normal reasons.

I'm not sure what you mean by "normal reasons"?

> So that suggests that the HTTP URI for the package, which names it, be the
> reference point for things inside the package, to identify them.
>
> Why not adopt the convention that one just continues with a slash?
>
> http://example.com/widgets/2007/blink-01.zip/contents/chrome/js/blink.js

That would make little sense. How would the widget engine then
differentiate between a URL on the web and a URL to the widget
package?

> This would mean the server would have to reply to it either with a response
> indicating "You have asked for part of a package X, go get the package" or
> it could say You have asked for part of a package X, here is what you asked
> for" and extract it.

I'm not sure I understand what you are saying, but, assuming I had
already downloaded blink-01.zip, that would be expensive as it would
require an additional HTTP request every time I wanted to do something
(eg. an image rollover). Why not just bypass the whole asking the
server thing and just refer to things locally with "widget://"?

Also, by introducing HTTP, how would the widget engine cope with
non-GET requests when the widget engine has not actually been designed
to cope with HTTP semantics? Claiming to "talk" HTTP but not actually
supporting it would be a violation of HTTP. So that's yet another
reason for using "widget://", as it does not imply that the widget
engine understands HTTP semantics/requests.

More fundamentally (and interestingly), adding HTTP semantics to a
widget user agent fundamentally changes what a widget user agent is.
Our current architecture is that the widget user agent acts like a
browser with a local cache. The widget engine can make HTTP requests
to servers, but can only "GET" things from within the widget resource.
Hypothetically speaking, one reasonable way that I see to introduce
HTTP into the mix here is to make the widget engine addressable as a
local web server:

http://widgetengine:port/instanceID/package.wgt/path/to/resource

This would allow for the widget engine to understand HTTP semantics
and appropriately respond to requests (eg. the widget could POST to
themselves and eventually, eachother, etc).

Introducing HTTP into the mix changes the widget user agent from a
browser+cache to a browser+server+cache. Such an architecture is
pretty cool, because you can then do all sorts of fun stuff (eg. add
PHP to the widget engine for server-side processing... I wrote a blog
entry about this a while ago, if anyone is interested [1]). I'm
willing to discuss the idea of adding HTTP further (personally because
I feel it would make for a pretty awesome widget engine), but I have a
feeling that we may be going outside the scope of the WAF Working
Group.

Kind regards,
Marcos

[1] http://datadriven.com.au/2007/12/17/omg-im-a-server-widgets-and-the-exciting-future-of-mobiles/

-- 
Marcos Caceres
http://datadriven.com.au

Received on Thursday, 29 May 2008 00:46:05 UTC