W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2008

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

From: Mark Baker <distobj@acm.org>
Date: Wed, 8 Oct 2008 11:28:42 -0400
Message-ID: <e9dffd640810080828l7ddac683h6056faaf241ea190@mail.gmail.com>
To: "Marcos Caceres" <marcosscaceres@gmail.com>
Cc: public-webapps <public-webapps@w3.org>

Marcos - IIRC, there was little or no support for a widget URI scheme
in the discussion on www-tag.  Why are you continuing to move ahead
with it?

Note that you'll still have to get this past IANA who maintains the
registry.  IANA uses a process specified in RFC 4395 which says;

   The use and deployment of new URI schemes in the Internet
   infrastructure is costly; some parts of URI processing may be
   scheme-dependent, and deployed software already processes URIs of
   well-known schemes.  Introducing a new URI scheme may require
   additional software, not only for client software and user agents but
   also in additional parts of the network infrastructure (gateways,
   proxies, caches) [11].  URI schemes constitute a single, global
   namespace; it is desirable to avoid contention over use of short,
   mnemonic scheme names.  For these reasons, the unbounded registration
   of new schemes is harmful.  New URI schemes SHOULD have clear utility
   to the broad Internet community, beyond that available with already
   registered URI schemes.

  -- http://tools.ietf.org/html/rfc4395#section-2.1


On Tue, Oct 7, 2008 at 1:31 PM, Marcos Caceres <marcosscaceres@gmail.com> wrote:
> Hi All,
> I think, for V1, that we should drop the authority part of the widget
> URI scheme and leave it as an implementation detail (but add a note
> saying that we might add a scheme in V2). I propose this because we
> don't currently have an API or security/interaction model for
> cross-widget communication and I don't think we will get one by the
> end of the year (not from me, anyway... and I haven't seen any other
> member put forward any real viable solution to this problem).  Another
> reason is that it simplifies the widget URI scheme, but still allows
> us to expand on it later (v2).
> My proposal is:
> widget-uri = "widget://" path-absolute ["#" fragment]
> (query strings are not supported (ignored) in v1)
> In other words, DOM nodes would be resolved to:
> widget:///someFolder/SomeFile.ext#someFragment
> I'm also not convinced that uniquely identifying the widget should be
> part of the authority (if we do decide to use it, would it b more
> appropriate to  hijack the :port?). For example,
> widget://:a34af23bh23/myFile.png
> Marcos
> --
> Marcos Caceres
> http://datadriven.com.au
Received on Wednesday, 8 October 2008 15:29:30 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:12 UTC