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: Fri, 10 Oct 2008 15:09:16 -0400
Message-ID: <e9dffd640810101209v49c6ef4av6fd900940e526205@mail.gmail.com>
To: "Marcos Caceres" <marcosscaceres@gmail.com>
Cc: public-webapps <public-webapps@w3.org>

On Fri, Oct 10, 2008 at 2:25 PM, Marcos Caceres
<marcosscaceres@gmail.com> wrote:
> 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:
> myWidget.wgt
>  /scripts/engine.js
>  /images/hello.gif
>  /cat.html (chinese)
>  /config.xml
>  /en/cat.html
>  /en/images/hello.gif
>  /jp/cat.html
>  /jp/images/hello.gif
> 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>

That's still a relative reference, so I have no problem with it.

What I'm asking is whether an author would ever need to use a full URI
to a local part?

>>> 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.

Ok, it doesn't really matter from my POV.

But with regards to my last remaining question to you (above), if the
answer is "No", then I think the answer for the URI scheme is "Any
hierarchical URI scheme".  So if one agent wants to internally use
file: and another wants to use ftp:, then they can do so and still
successfully process the same packaged widget.  The choice of the URI
scheme is an implementation detail.

Received on Friday, 10 October 2008 19:10:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 14:36:31 UTC