Fwd: [widgets] Widgets URI scheme

With Stuarts permission, I'm forwarding a discussion I've been having
with Stuart about Widget URIs.

---------- Forwarded message ---------
From: Marcos Caceres <marcosscaceres@gmail.com>
Date: Tue, Aug 5, 2008 at 9:20 PM
Subject: Re: [widgets] Widgets URI scheme
To: "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>
Cc: Arthur Barstow <Art.Barstow@nokia.com>


Hi Stuart,

On Tue, Aug 5, 2008 at 7:22 PM, Williams, Stuart (HP Labs, Bristol)
<skw@hp.com> wrote:
> Hello Marcos,
>
> I'm sorry. I have not been able to make much progress - the TAG attention has been ceased elsewhere of late (XRI) and the summer time has intruded. I am here for the remainder of this week and am then away for nerly 2 weeks on a family vacations. [The day job also intrudes :-(]. The TAG itself does not meet again until 28th Aug... so I think it unlikely that I/we will have been able to produce much of use for your F2F. .

That's ok. We will keep working on the problem and keep you in the
loop with any progress.

> wrt http://dev.w3.org/2006/waf/widgets-reqs/#r6.-addressing
>
> Perhaps you could help me understand this a requirement a little more. It speaks of addressing "individual widget instances" and of "allowing widgets to address each other". Not being steeped in widgets I'd like to understand what is meant by the quoted phases.
>

No, it's ok. It's a bit confusing. I guess the idea is that you should
be able to do some kind of cross widget messaging. For example (and
this is just a dumb hypothetical example), your email-checker widget
might automatically "tell" your calendar widget to when someone sends
you an email requesting a meeting.

> I can see that a wiget resource is a package that contains a number of resources from which a wiget can be instantiated;

That is correct.

> I can see that there is a need to be able to refer to the wiget resource (the package) as a whole for the purposes of instantiating a widget;

That is correct.

> I can see that there is possibly a need to be able to refer either internally within or externally into the packaged widget resource.

That is correct. Though a widget cannot address the resources of
another widget.

> However, I assume that a given widget may be instantiated multiple time on a given page or within a given web application and there is a need to be able to refer to an instantiated widget (within a client) and presumably to be able to refer resources within the package from which it was instantiated; I can also see that there may be a need for instantiated widgets to be able to refer to each other.
>

That is correct also. However, at this point, we are not really
looking at instantiating widgets inside web documents. They are
standalone applications that run within the context of a widget engine
(which can be a browser, as is the case with Opera widgets).

> What is less clear is whether the identifiers for widget instances need to be public globally scope identifiers or whether they are a very local matter for the web application platform - ie. whether they are really transient run time phenomena like a process ID in an OS - sure a globally scoped identifier would do - but is there a requirement to be able to make external references to a widget instance?
>

Personally, I would be ok with them being process IDs or an
implementation detail. In fact, as the widget uri scheme can only be
used by the widget engine, it could be left as an implementation
detail. However, I think we will eventually need some kind of URI
scheme for addressing inside packages so defining a URI scheme is
really a preemptive action.

> On packaging formats a couple of TAG member have asked (at least in TAG meetings and possibly more visibly) what existing alternative means of packaging and reference you have considered. In particular Henry mentioned multipart MIME and that was echoed by Larry Masinter [1]. Admittedly you may require compression aswell, but I'm interested whether the intra widget package addressing requirements can be met in that way. You respond on that point below, but don't say why multi-part MIME was unsuitable.
>

Admittedly, I don't know MIME very well. However, from what I can tell
multi-part MIME is unsuitable because:

1. lack of packaging tools for MIME (zip is more prevalent and ships
with almost every OS)
2. difficult for authors to work with compared to zip: zip ships
natively with many operating systems (such as WindowsXP/Vista/S60) and
allows authors to easily modify the content of packages.
3. lack of compression
4. all widget engines already support Zip, so using MIME would be
"going against the grain" with regards to standardization and would
delay implementation as widget engines may need to be significantly
changed to support MIME.

> Personnally I'd like to find a solution that does not require a URI scheme definition - I'd be much more comfortable with a media-type based solution.

Like I said, I don't really know MIME very well, so I'm completely
open to hear your ideas on how MIME would work as a packaging format
for widgets. However, please be mindful that the working group (and
implementers) are pretty much set on Zip and it think it would be a
hard battle to get the to shift their position. In other words, MIME
will need to do something pretty spectacular to dethrone Zip as the
preferred packaging format for widgets.

Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au

Received on Thursday, 7 August 2008 07:57:02 UTC