Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.

Hi Stuart,
Sorry for taking so long to reply...
On 12/15/08 3:16 PM, "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>
wrote:

> Hello Marcos,
> 
<snip/> 
> At the TAG F2F last week we began to start discussing responding to the direct
> request that you made to us for feedback:
> 
> http://lists.w3.org/Archives/Public/www-tag/2008Nov/0114.html "...I again ask
> the TAG for direct feedback on the following URI-related requirements, which I
> have modified post the F2F meeting."
> 
> You go on to quote requirements R6 and R36.
> 
> We persued R6 and chased down some discussion of configuration documents and
> thence found:
> http://dev.w3.org/2006/waf/widgets/#step-1 ins the chapter of Widget spec
> titled:
> 
>         "8. Steps for Processing a Widget Resource"
> 
> ...in particular step (#1) titled:
> 
>         "Step 1 - Acquire a Potential Zip Archive from the Network, or from
> Local Storage or Other Media"
> 
> which suggests that networked based acquisition of widget resources is very
> much part of your design. Given what you have said that has left the TAG and I
> a little confused about your requirements for networked references.

In regards to network acquisition, the processing that occurs in Step 1 just
refers to downloading zip files (not acquiring the resources from within a
package that is somewhere on the network).
 
> It strikes me that *if*, as appears to the case, there is a potential need to
> be able to reference, obtain/install widget packages across the network, then
> you should factor that into your design early. I see 3 broad requirements:
> 
> 1) relative addressing withing the package -
>    basically uri: scheme-less with absolute (from package root) or relative
> paths.
>    question arises of how to turn internal relative references into absolute
> URI.

This is exactly the only problem WebApps-WG was trying to solve. This is the
highest priority for the WebApps-wg wrt Widgets 1.0.
 
> 2) referencing into a package from 'outside' -
>    which requires some means to refer to the package as a whole plus
>    an approach to refering inside the package.

Until now, this was _not_ a problem that WebApps was trying to solve.
However, you have convinced me that this will be useful in the future and I
would like to pursue it for Widgets 2.0.
 
> 3) [Possibly] referencing between instantiated widgets -
>    (ie referencing run-time objects rather than the (shared?) package(s) from
> which they are instantiated.)

This is a low priority item for Widgets 1.0. It is unlikely that it will
make it into the spec. However, it is something that we may pursue in
Widgets 2.0.   
 
> Can you help us more specifically with set of scenarios that more clearly
> illustrate your requirements for networked package/widget referencing and
> access?

Like I said, our main priority is 1). Simply:

 1. Get widget package from HTTP(S): e.g., http://example.com/myWidget
 2. Does it have the right MIME type? I.e., "application/widget"
 3. If so, is it a zip file that conforms to the Widgets 1.0: Packaging
spec? 

Our second priority is to instantiate the widget from local storage. As
there is no notion of MIME, that involves checking the file extension and
doing content-type sniffing.

> BTW: When it comes to some page/web-app instantiating a widget... how does the
> publisher/developer make reference to the widget to be instantiated and/or the
> package from which it is to be instantiated (if those are regarded as separate
> things)?

I'm sorry, I'm not sure I understand your question. Could you rephrase it or
give me an example. FWIW, we have removed all requirements for Widgets to be
embeddable into Web documents. Widgets, as currently being defined by the
Widgets 1.0 Family of Specifications, are solely packaged standalone
client-side applications that are authored using Web technologies.

Kind regards,
Marcos

Received on Tuesday, 20 January 2009 15:32:27 UTC