Hi,
It seems to me that Requirement 6 should be split into two requirements:
A. "A conforming specification MUST specify or recommend an addressing scheme to address the individual resources within the widget resource at runtime."
B. "A conforming specification MUST specify or recommend an addressing scheme to address individual widget instances."
For requirement A, I think that, given that the WG specifies a Packaging Format for Widget, it could define as well a Fragment Identifiers syntax for this package. This would have the advantage of separating/hiding the protocol used to retrieved the widget and therefore address the problem of "The addressing scheme MUST NOT expose the underlying file system (if any)". I think authors are also used to that mechanism and therefore would satisfy "The addressing scheme SHOULD be one that web authors would feel comfortable using or to which they are already accustomed."
For requirement B, correct me if I'm wrong, but since the exact identifier of a widget instance can only be known at runtime, I don't see how an author can determine it declaratively as a URL before instantiation. So, the URL to the widget instance has to be created at runtime as well. Therefore, I imagine that there could be an API to do the following: querying the available widget instances, then requesting a URL (internal to the User Agent) to a particular widget instance and finally creating the final URL using the previous URL and appending a proper fragment identifier.
Therefore it seems to me that a new URI scheme is not necessary. Where is my reasoning wrong?
Regards,
Cyril
Marcos Caceres a écrit :
> Hi Mark,
> On Thu, Oct 9, 2008 at 6:00 AM, Mark Baker <distobj@acm.org> wrote:
>> On Wed, Oct 8, 2008 at 3:35 PM, Marcos Caceres <marcosscaceres@gmail.com> wrote:
>>> <snip>
>>>> Any hierarchical URI scheme would seem to be able to meet those
>>>> requirements. So why not, for the sake of argument, file:?
>>> Yes, file: might be ok. But where is the spec that defines file:? I
>>> can't find it.
>> Good question. At least twice during the past 15 years or so,
>> somebody's tried to write a spec for it, but both times that's ended
>> in failure (e.g.
>> http://tools.ietf.org/id/draft-hoffman-file-uri-03.txt ). I brought
>> it up only as an example, because it doesn't carry all that "network
>> resource" mental baggage that many people commonly associate with
>> schemes such as ftp or http. It's still possible to use it of course,
>> as long as the fuzzy areas are avoided.
>>
>
> I see what you mean, the Hoffman draft above reads more like a "here
> is a list of what is wrong with file:" rather than a spec. And rfc1738
> has been obsoleted.
>
>> 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. The reason we don't
> want to allow vendors to mint their own is that there are potential
> security and privacy issues related to URI schemes such as file:. For
> instance, because Dashboard uses "file:" it is very easy for me to
> work out what the username and home directory of a user on MacOsX by
> simply picking up any DOM node that contains a dereferenced URI (eg.
> by examining an img's src, I get something like
> "file:///Users/marcos/Library/widget/Default.png").
>
> 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
>
> Kind regards,
> Marcos