Re: [Widgets] URI Scheme revisited.... again

Hi Mark,
On Thu, Oct 9, 2008 at 6:00 AM, Mark Baker <distobj@acm.org> wrote:
> On Wed, Oct 8, 2008 at 3:35 PM, Marcos Caceres <marcosscaceres@gmail.com> wrote:
>> <snip>
>>> Any hierarchical URI scheme would seem to be able to meet those
>>> requirements.  So why not, for the sake of argument, file:?
>>
>> Yes, file: might be ok. But where is the spec that defines file:? I
>> can't find it.
>
> Good question.  At least twice during the past 15 years or so,
> somebody's tried to write a spec for it, but both times that's ended
> in failure (e.g.
> http://tools.ietf.org/id/draft-hoffman-file-uri-03.txt ).  I brought
> it up only as an example, because it doesn't carry all that "network
> resource" mental baggage that many people commonly associate with
> schemes such as ftp or http.  It's still possible to use it of course,
> as long as the fuzzy areas are avoided.
>

I see what you mean, the Hoffman draft above reads more like a "here
is a list of what is wrong with file:" rather than a spec. And rfc1738
has been obsoleted.

> But I wonder whether the scheme really matters very much.  What kind
> of intra-package references do you expect to be able to resolve?  Will
> they all be relative, or will there be absolute ones?  If it's just
> relative references, then any hierarchical one will do, as the
> consuming user agent can just mint their own base, be it an http URI,
> a file URI, or otherwise.

We use both relative and absolute URI references, and the base is
derived from the i18n model we have introduced. The reason we don't
want to allow vendors to mint their own is that there are potential
security and privacy issues related to URI schemes such as file:. For
instance, because Dashboard uses "file:" it is very easy for me to
work out what the username and home directory of a user on MacOsX by
simply picking up any DOM node that contains a dereferenced URI (eg.
by examining an img's src, I get something like
"file:///Users/marcos/Library/widget/Default.png").

Personally, the solution I keep coming to is something like :

widget-uri = "http://" widget-engine [":" instance-id] "/"
package-name path-absolute ["#" fragment]

Where widget-engine is something akin to using, say, "localhost", but
uses some arbitrary string that identifies the engine (e.g.
theFooEngine). The optional instance-id would be a string that
uniquely identifies a widget instance for the purpose of cross-widget
communication. However, I can foresee that there may be problems with
thieving http's port semantics to uniquely identify an instance (so we
leave this out until version 2). The scheme would only support GET
requests. For example,

http://theFooEngine/barWidget.wgt/index.html#welcome

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

Received on Thursday, 9 October 2008 10:57:46 UTC