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

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.

Mark.

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