On Fri, Oct 10, 2008 at 2:25 PM, Marcos Caceres <[EMAIL PROTECTED]> wrote: > Hi Mark, > > On Fri, Oct 10, 2008 at 6:37 PM, Mark Baker <[EMAIL PROTECTED]> wrote: >> On Thu, Oct 9, 2008 at 6:57 AM, Marcos Caceres <[EMAIL PROTECTED]> 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.
