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

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

Ok... I'll try, though I have read very little of the widget spec material, just the bits around addressing.

When some webapp developer is developing a webapp they will have to refer in some way to the wigets that they want to use in their application - particularly for the cases where they expect some network retrieval to go on. All I'm asking is *how* they make that reference? 

- Just a URI refering to (a copy of) the Widget package; 
- some location independent Widget (package?) name? 
- a two part name (naming the package and naming the widget within the package)?

> FWIW, we have removed all requirements for Widgets to be
> embeddable into Web documents.

When you say "removed all requirements" that doesn't say that current specs don't provide any capabilities there - only that you don't require them to. So... whilst it may not be something that you currently require do the specs that you are working on address or partially address embedding of widgets in 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.

BR

Stuart
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

> -----Original Message-----
> From: Marcos Caceres [mailto:marcosscaceres@gmail.com] 
> Sent: 20 January 2009 08:47
> To: Williams, Stuart (HP Labs, Bristol)
> Cc: www-tag@w3.org; public-webapps; 
> public-pkg-uri-scheme-request@w3.org
> Subject: 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 16:33:15 UTC