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

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

From: Marcos Caceres <marcosscaceres@gmail.com>
Date: Fri, 10 Oct 2008 19:25:15 +0100
Message-ID: <b21a10670810101125h38534197nafe7d131e5eb3a59@mail.gmail.com>
To: "Mark Baker" <distobj@acm.org>
Cc: public-webapps <public-webapps@w3.org>

Hi Mark,

On Fri, Oct 10, 2008 at 6:37 PM, Mark Baker <distobj@acm.org> wrote:
> On Thu, Oct 9, 2008 at 6:57 AM, Marcos Caceres <marcosscaceres@gmail.com> wrote:
>>> 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.
> Ok, I see that, but I don't see why you'd want to then use absolute
> references in the widget content.  Is it your intention that widget
> authors would have knowledge of the base URI (or the algorithm)?  From
> my POV, you'd want them authoring links to other widget parts using
> only relative references, like ZIP and all other packaging formats I
> know of do (at least those supporting hierarchical containment).

Yes, that is certainly a possibility, but there are situations where
you might want both types (or, at least, it is less annoying for
developers because they won't have to type "../../" everywhere). For
example, I have a simple localized widget that has the following
directory structure:

  /cat.html (chinese)

so, cat.html could work off the same JS code while having a have
completely custom layout as needed:

<!doctype html>
<script src="/scripts/engine.js">
<img    src="images/hello.gif">
<p>Hai! bla bla bla</p>

>> 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
> Or just http://localhost/theFooEngine/barWidget.wgt/index.html#welcome ?

The problem with localhost is that you may have Apache or some other
web server running that you want to interact with (e.g., during
development testing); In which case, you would have to request
permission to via the configuration document to access the network
(localhost). I don't think it would be good to override localhost
unless the widget engine was actually going to serve content. If the
widget engine was going to behave like a web server, then yes, by all
means use localhost.

I think that pretty much explains my rationale with regards to the URI
scheme for widgets. I'm not sure how to proceed from here.

My inclination at the moment is that in the packaging spec I will
mandate that widget user agents to resolve everything to absolute
paths (but retain the character  encoding of each file name (noting
that encoding of file names can vary from one file to another)). I
fear that the URI issue will become a huge block for us (WebApps) and
won't allow the specification to progress from LC. Once we resolve
this URI issue (possibly in another spec), then all absolute paths
derived during processing of the config.xml file can be correctly
dereferenced (and properly encoded so they can be used in the DOM).

Kind regards,
Marcos Caceres
Received on Friday, 10 October 2008 18:25:58 UTC

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