W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2008

[widgets] Minutes from 20 October 2008 f2f meeting

From: Arthur Barstow <art.barstow@nokia.com>
Date: Tue, 21 Oct 2008 16:39:28 -0400
Message-Id: <9BCD9933-844D-4B02-AFEC-2D912EF84A30@nokia.com>
To: public-webapps <public-webapps@w3.org>

The minutes from the October 20 Widgets f2f meeting are available at  
the following and copied below:


WG Members - if you have any comments, corrections, etc., please send  
them to the public-webapps mail list before October 23 (next Widgets  
voice conference); otherwise these minutes will be considered approved.

-Regards, Art Barstow


       [1] http://www.w3.org/

                                - DRAFT -

                           Widgets f2f Meeting

20 Oct 2008


       [2] http://www.w3.org/2008/webapps/wiki/WidgetsMandelieuAgenda

    See also: [3]IRC log

       [3] http://www.w3.org/2008/10/20-wam-irc


           Mark, David, Claudio, Benoit, Marcos, Art, Arve, Mike,
           Fabrice_Desre, Paddy, Josh, Sophie_Aveline, Hyunjeong_Lee,
           Nick, Larry_Masinter, Dan_Connolly, Noah_M, Norm_Walsh,
           Ashok_Malhotra, Oracle, TAG, Stefano_Crosta, Henri, Hixie,




      * [4]Topics
          1. [5]Introductions
          2. [6]Agenda review and tweaking
          3. [7]Issue #46 - I18N
          4. [8]Section 5.4 Need validator's point of view
          5. [9]Section 5.5 Need for a MIME type
          6. [10]Version String in Section 6.14
          7. [11]Section 7 Need to add cp437 text
          8. [12]Section 8.2 - What do we do if run out of space?
          9. [13]Section 8.2, Step #10 - How to handle SVG Icon Formats
         10. [14]Section 8.2, Step #11 - Is additional security model
             needed here?
         11. [15]Prep for URI scheme meeting with the TAG
         12. [16]Joint meeting with TAG Members regarding Widget URI
         13. [17]Section 8.2, Step #11 - Need to describe what happens
             if the widget already exists
         14. [18]Section 9.1 locating thumbnails
      * [19]Summary of Action Items

    <timeless> that reminds me, i should d/l the maps + favorite the

    <abarsto> Date: 20 October 2008

    <abarsto> Scribe: Art

    <abarsto> ScribeNick: ArtB

    <timeless> 10a. Can you invite zakim?


    <abarsto> [ round robin of Widgets people mostly ]

    <abarsto> Fabrice: Orange/FT AC rep

Agenda review and tweaking

    <abarsto> AB: agenda:

      [20] http://www.w3.org/2008/webapps/wiki/WidgetsMandelieuAgenda

    <abarsto> AB: any changes or additions?

    <abarsto> MP: what about OpenAjax's API style guide?

    <abarsto> AB: how about I add it to AOB?

    <abarsto> MP: OK

    <abarsto> AB: I can also ask Chaals to let us know if/when he
    discusses it

Issue #46 - I18N

    <abarsto> AB: what remains to be done with this issue?

    <abarsto> MC: I have addressed this issue in the spec

    <abarsto> ... The main issue is how to address LtoR and RtoL in the
    same piece of text

    <abarsto> ... I added OPTIONAL support for the ITS' span element

    <abarsto> ... If supported must support its:dir atrribute too

    <abarsto> ... Not clear if we need to bind its:dir to widgets
    description or name element.

    <abarsto> ... Thus I need to clarify with the I18N WG

    <abarsto> ... This also means I needed to change our RELAXNG schema

    <abarsto> AB: any recommendations on the its:dir binding issue?

    <abarsto> ... It would be optional, right?

    <abarsto> MC: yes, it would be optional

    <abarsto> AB: OK, so we leave this open for now

    <abarsto> ... and try to close it by the end of this meeting.

    <abarsto> MC: If I can meet with Felix we can close this today

    <abarsto> MS: yes, I can make that intro.

    MC: this issue surfaces because ZIP encodes filename differently on
    different OS's e.g. Mac does it one way and Widows does something
    differentMS: if we are doing something differently from other specs
    i.e. the URI or IRI specs, I would be concernedAB: does this mean
    there is a hole in the IRI specMC: no; the problem is different OS's
    handling... we need to take care of these interop probsAB: action
    plan is what then?

    [ MC demonstrates some of the interop issues ... ]

    AB: what's the action plan?

    MC: I need to implement what's spec'ed

    AB: does this need to be done before LC?

    MC: yes

    AB: can anyone help Marcos?

    [ No voluneeters :-( ]

    BS: can someone here at the TPAC help?

    MC: it's a bit ugly and nitty-gritty
    ... but I can do it
    ... Need to actually look at the ZIP files in hex

    [ MC shows HexEdit example of a .zip file ]

    <scribe> ScribeNick: ArtB

    MC: if not utf8, use cp437
    ... I think Josh can help me

Section 5.4 Need validator's point of view

    MC: this was raised by Dom
    ... I added some related text to the definitions
    ... Also need to reflect the view of a validator
    ... I don't think this is a high priority
    ... If someone wants to contribute, that would be good

    AB: any volunteers for a conformance checker?
    ... perhaps we can some W3C staff/webreq help
    ... I'll check with Mike

    <scribe> ACTION: Barstow see if the W3C systeam/webreq can help with
    a conformance checker [recorded in

    <trackbot> Created ACTION-257 - See if the W3C systeam/webreq can
    help with a conformance checker [on Arthur Barstow - due

    AB: I would imagine that type of service could be included in a
    Widget repository service

    MC: something like this could be added to validator.nu

    AB: this is Henri's service?

    MC: yes, but just giving a schema isn't that helpful
    ... need to provide "hints" too
    ... I believe validator.nu is Open Source so we could roll our own
    ... the note in Section 5.4 has been removed since I think its
    priority is too low

Section 5.5 Need for a MIME type

    AB: [22]http://dev.w3.org/2006/waf/widgets/#mime-type
    ... a potential sub-issue here is Security Concerns
    ... I would expect IANA to have a template for what's required
    ... RFC 4289 defines the process

      [22] http://dev.w3.org/2006/waf/widgets/#mime-type

    [ We spend some type looking at the W3C/IANA MIME registration
    procedures ]

    AB: do we need to complete the template?
    ... We can check the precedence
    ... a question I have is if we need to complete the template before
    we publish a LC doc

Version String in Section 6.14

    AB: [23]http://dev.w3.org/2006/waf/widgets/#the-version (now in
    section 6.15)
    ... what are you looking for?

      [23] http://dev.w3.org/2006/waf/widgets/#the-version

    MC: that should not be there
    ... this should be in the update spec, not P&C

    MP: if it is in the Update spec then where?

    MC: in the update element

    MP: if you want version info in the widget but won't have an update,
    what do you do?

    PB: so version attribute on widget element remains?

    MC: yes

    AB: so the update element will have a verison attribute too?

    MC: yes

    <scribe> ACTION: Macros move the version string section from P&C
    spec to the Updates spec [recorded in

    <trackbot> Sorry, couldn't find user - Macros

    <scribe> ACTION: Marcos move the version string section from P&C
    spec to the Updates spec [recorded in

    <trackbot> Created ACTION-260 - Move the version string section from
    P&C spec to the Updates spec [on Marcos Caceres - due 2008-10-27].

    MC: there is another spec being written by David Orchard re template
    for attributes
    ... I have used text from URI Template (RFC working draft)

    <scribe> ACTION: Barstow determine the status of URI Template RFC
    and report back to WG [recorded in

    <trackbot> Created ACTION-261 - Determine the status of URI Template
    RFC and report back to WG [on Arthur Barstow - due 2008-10-27].

    MC: another discussion we can have is the use of this template
    mechanism for other elements in the Updates spec

    AB: do we need to consider its usage in the P&C spec?

    MC: no
    ... we can use OMA's DL spec e.g. for status codes
    ... regarding the Update spec.

Section 7 Need to add cp437 text

    AB: the agenda mentions this issue but I think it has now been
    ... Is that right, Marcos?

    MC: yes, consider this part of the URI/IRI proc model discussion we
    had earlier.

    [ Take a Coffee Break ]

Section 8.2 - What do we do if run out of space?

    AB: status Marcos?

    MC: I removed this because it is an implementation issue
    ... Josh added this

    ABe: I agree it is an implementation detail for the P&C spec
    ... also agree it is a real implemenation detail for an

    MC: I changed related text

      [27] http://dev.w3.org/2006/waf/widgets/#extracting

    ABe: I think the new text is sufficient

    AB: Josh, what do you think (you raised this issue)?

    MC: I would expect an impl to use the ZIP header to determine the
    space needed and do the right thing

    JS: this is OK with me

Section 8.2, Step #10 - How to handle SVG Icon Formats

    AB: see [28]http://dev.w3.org/2006/waf/widgets/#step-10
    ... what can we expect to do with this issue?

      [28] http://dev.w3.org/2006/waf/widgets/#step-10

    MC: we need feedback from implementors
    ... need to understand the interactivity e.g. if the SVG has some

    ABe: the JS could run outside of the widget
    ... We wouldn't be able to do anything about security in that case

    MC: my feeling is we should drop SVG for v1
    ... and add it to v2

    ABe: the problem that will introduce is that most operators will
    require SVG for icon formats

    MP: yes, I believe that is true for us

    JS: it's not just a graphics format (and static) but it can also be
    an app format i.e. actually running as the "main" widget

    CV: we need to support SVG Tiny
    ... and 1.2 is preferred

    MC: we have an open issue regarding 1.1 vs 1.2
    ... the issue is how to handle the events on the icon e.g. via XHR
    ... the question is do we allow that
    ... Will it introduce too much implementation burden

    BS: think the most important requirement is the image format
    ... and interactivity is secondary importance
    ... I think the most common usage is static icon images

    AB: any other comments?

    MC: I think we should leave this as an impl detail
    ... it is optional to support SVG as an icon format

    AB: if we do that, what interop probs will there be?

    JS: could add a should for widget authors re SVG icon format

    ABe: not sure about use of should; could be too strong
    ... perhaps should use MAY

    MC: I've stopped using normative text regarding authoring reqs

    JS: so it's more of a hint in this case?

    MC: yes

    ABe: we could remove the entire author req

    MC: no, I disagree; want to keep it
    ... but those who want it will add; otherwise they won't

    AB: are these "Author Requirements" non-normative?

    MS: don't call them "Guidelines"
    ... perhaps they should be in a sep doc

    JS: we could leave them in for now

    MC: yes, they could be in a separate doc

    AB: are these Autho Reqs normative or non-normative?

    MC: I think they should be Normative

    MS: If we are going to build a validator, they should be Normative
    ... are there constraints that cannot be expressed in a schema?

    MC: yes, some of the ZIP constraints

    MS: if you want these reqs to be in the validator, they should be

    MC: agree; DOM raised a similar issue
    ... perhaps the Author reqs should be changed to "Conformance

    MS: that is what HTML5 does
    ... with some text to qualify relationship to authoring

    MC: I can re-write all of the Author Reqs to Conformance Reqs and
    make them all Normative

    AB: any objections?

    [ None ]

    JS: should we check with Hixie re HTML5?

    MC: I talked to HTML5 this morning
    ... he is considering a script to move authoring stuff into a sep

    JS: I'm OK with doing this way

    MC: there is another issue
    ... this could be a problem if we add a new "Product"
    ... We would now have a 4th product.
    ... And the Conformance Checker can claim conformance to the spec

    AB: can you do that?

    MC: yes, I can do that
    ... let someone else create the Conformance Checker.

    AB: any volunteers?

    RESOLUTION: all of the Author requirements will be changed to
    Conformance Checker requirements and all of these requirements will
    be Normative.

    LM: I don't recall seeing a good definition of Conformance Checker

    MC: I hope that isn't a rat hole
    ... HTML5 attempts to make such a definition

    MS: we could look at what has been done in HTML5

Section 8.2, Step #11 - Is additional security model needed here?

    AB: [29]http://dev.w3.org/2006/waf/widgets/#step-11
    ... what
    ... is the issue?

      [29] http://dev.w3.org/2006/waf/widgets/#step-11

    MC: this may be out of scope for this spec
    ... Not sure we need to go beyond what is specified

    AB: what do people think?

    PB: not sure what the security issue is

    MC: need to spec how to put something on the screen and what we need
    to say about runtime requirements
    ... eg. if the widget tries to do something that raises a security
    ... What do we specify regarding instantiation e.g. security
    ... does HTML5 deal with this?

    MS: the latest ED of HTMl5 doesn't say anything about rendering

    MC: I could talk to Hixie

    MS: we could ask for an Editor to draft some text

    PB: within BONDI, we are interested in the security policy related
    to the instantiation

    MC: we used to have a step #12 which tried to deal with this
    ... but it was remove because this is out of scope

    AB: I'm OK with leaving step #11 as is
    ... any objections to deleting the security model issue from Step

    [ None ]

    RESOLUTION: Step #11 of the P&C will not address the security model

    ABe: I'm uncomfortable with separating the P&C spec from Security
    ... e.g. it could create some new authoring issues

    MC: we do need to spec the security models
    ... expect BONDI to do some relevant work here that we may be able
    to use
    ... expect a separate policy doc from the config doc

    MP: agree, we envision the policy doc as a separate from the config

    MC: we could bind the config doc to the policy doc via the feature

    MP: we need to discus how to bind the security policy to the config
    ... could use the feature element
    ... Could add a new permissions element to the access element
    ... and it could contain a string that defines a permission

    MC: do you have an example of use case?

    PB: from MIDP, can use an API to open any channel (e.g. BT, Socket,
    ... If want generic APIs, need a way to grant permissions

    MP: may need to have different policies for different APIs

    [ Marcos enters an example into his ED draft ]

    <marcos> Option 1: <feature uri="[30]http://geoloc.com/a/b/c/d/" />

      [30] http://geoloc.com/a/b/c/d/

    <marcos> Option 2.<feature uri="[31]http://geoloc.com">

      [31] http://geoloc.com/

    <marcos> <param name="celltowers" value="true"/>

    <marcos> </feature>

    AB: we will add this topic to the agenda this afternoon or tomorrow

Prep for URI scheme meeting with the TAG

    [ Marcos shows preview of the slides he will present to the TAG ]

    <scribe> ACTION: Marcos send Widget URI scheme slides to one of
    {member,public}-webapps [recorded in

    <trackbot> Created ACTION-265 - Send Widget URI scheme slides to one
    of {member,public}-webapps [on Marcos Caceres - due 2008-10-27].

    <timeless> ScribeNick timeless

Joint meeting with TAG Members regarding Widget URI scheme

    <timeless> ScribeNick: timeless

    <ArtB> AB: I chair this WG

    <ArtB> MC: I am the Editor of this spec

    <ArtB> NM: member of TAG from IBM

    <ArtB> NW: Norm Walsh TAG

    MC: [ presents slideshow "Widget URI Scheme" ]

    <ArtB> DC: W3C, member of TAG

    MC: Widget is a client side application - that runs on your computer
    ... primarily it's a light application, written using web
    ... . Use cases include possibly embedding a widget into a web page
    ... - similar to embedding a flash applet into a web page
    ... - we aren't talking about Google Gadgets or Microsoft Gadgets
    ... . Our applications are packaged, they come in a zip file,
    ... all resources come in the file.
    ... We've gone through a requirements gathering phaze for the past
    two years
    ... OMTP has been gathering requirements for over a year.
    ... We have a landscape document which is undergoing review.
    ... And I'm also working on a Thesis describing this.
    ... Inside zip there is a header that says that the data contained
    in this file entry relates to this data.
    ... When you instantiate a widget, you need a way to tell the widget
    user agent that this widget
    ... resource lives within the zip file.
    ... The hierarchy refers to elements with-in the zip file.
    ... The reference exists within the DOM.
    ... We don't want the URI scheme to have the ability to reference
    things outside the resource.
    ... As we want to be able to embed widgets into web pages,
    ... we don't want them to conflict with browser handling.

    <noah> Stefano Crosta.

    AB: We have a slide for each of the candidates

    MC: file:...
    ... with dashboard widgets, if you query the dom node for an image,
    it will expose the full path to the image
    ... including the username.
    ... The current specification for file is obsolete.
    ... There is a new document which doesn't specify, but merely
    indicates errors in the handling.

    ABe: Using the file uri scheme is not an option for Opera
    ... as you can't reference a file: resource from another protocol.
    ... This reduces the number of possible exploits.

    MC: Mike does HTML5 specify the security boundary for http<=>file?

    MS: I don't believe it's that specific.

    MC: cid:...
    ... my personal opinion is that it's underspecified, especially
    involving encoding.
    ... although it would be possible for widgets to specify this.

    <DanC_lap> (cid: clearly doesn't meet the hierarchical requirement.
    the other arguments are much less strong)

    <DanC_lap> Norm Walsh, aka NDW

    NDW: If the packaging format was still open, then i think it could
    be considered

    <DanC_lap> "obscure" applies to widget: too. (as does "no standard"
    from the file: slide)

    NDW: but if you've already accepted Zip, then I understand that it
    doesn't fit.

    MC: http:...
    ... TimBL proposed it.

    <DanC_lap> (I wondered earlier if [33]http://engine/widget/path was
    analagous to
    blink.js . indeed.)

      [33] http://engine/widget/path
      [34] http://example.com/widgets/2007/blink-01.zip/contents/ 

    Noah: do you have update scenairos.
    ... if so, then I think you need to posit update scenarios

    <noah> If you have update scenarios, then you need to compare how
    the various schemes compare in supporting them.

    <noah> If you don't need update, then I would say that the
    incremental cost of declining POST/PUT/DELETE in HTTP is very low.

    MC: Suppose we do offer HTTP, then someone might choose to implement
    a server which did support POST

    Noah: Don't compare widget: to http: based on the different
    ... only compare them against the same baseline.

    ABe: in practice that would lead to user agents having two
    implementations of http.

    <DanC_lap> DanC

    DanC: yes

    <noah> User agent or server? Seems to me it's the server that
    declines POST/PUT/DELETE

    <DanC_lap> (two implementations of http: in browsers is cheaper to
    the rest of the community than two uri schemes)

    NDW: I assume these names are just names and that they aren't bound
    to other things.

    <noah> The user agent needs to respond properly to that status code.
    Existing user agents will do that, one would assume.

    <DanC_lap> (we somehow switched from evaluating proposal against
    requirements to pros/cons. I'll hang on to see if we get back, I

    MC: We've got no notion of origin in our widgets.
    ... There's no notion of authority.
    ... if we're tweaking http too much, at what point is it no longer

    DanC: tim's proposal is that the thing is on a web server.

    Noah: there are two ways to model this
    ... in one model there's a web server in the form of a proxy.
    ... as long as there's some way to assign a uri to it.

    MC: you're talking about identity.

    JS: what happens when you die>

    noah: that sucks< you can put that into the Cons list

    <DanC_lap> (I gather widget: uses guids. you can stick guids in
    domain names, eg. 123412lkj132.noah-medelsohn.com )

    noah: but what happens if someone goes to IANA and steals the widget

    MC: the real use case for this is resolving the dom nodes.
    ... images, iframes, they all need to resolve to something.

    <Norm> So, is it the case that you require the ordinary, web agent
    built-in URI resolution system to resolve the URI. That is, if it's
    [35]http://example.org/... the web browser is going to do the
    natural thing

      [35] http://example.org/...

    JS: then you have the security problems evidenced by MHTML, CHM and
    a couple of other packages with shadowing.

    <Norm> ...which is to connect to that site.

    <DanC_lap> (I heard him say they identify widgets with unrestricted

    Noah: is it a potential pro that there's transparency so that the
    same widget could be deployed on the real web?

    <Norm> I believe there's a distinction between identifying the
    widgets themselves, and the *resources inside the widgets*

    Noah: granted that the caching is a complexity.

    JS: widget model has atomicity
    ... and there's already an update spec which handles updates

    AM: so you're describing something which is very specific to this
    ... it's just used for resolving names.

    ABe: it's only a convenience for resolving resources

    NDW: do you have a slide describing sample widget: uris?

    MC: no (not a slide)

    NDW: anything would be ok

    <DanC_lap> (hmm... where did I see widget: with a guiid)

    MC: we do have examples.

    JS: DanC: one of the potential candidates...

    MC: I'm just showing a few options

    widget: //widgetEngine/pack.wgt/some/path
    ... //widgetEngine/pack.wgt/some/path/to/file
    ... //pack.wgt/some/path/to/file.png

    NDW: so Noah and I have both made the world's greatest clock app?

    widget: //{uuid}/path/to/file.png

    <DanC_lap> (where do widget: uris occur? I gather only paths occur
    in href/src attributes)

    BS: In terms of ...

    Noah: traditionally when you have those things happening
    ... one is that you have something obscure (like a uuid)

    <DanC_lap> (also, the "what happens when you die and somebody takes
    over your domain?" concern applies to /someEngine/ too, yes?)

    Noah: are these things used to name the product?
    ... or are they something transient?
    ... If you're doing product naming then you have to run a registry.

    MC: digital signature document covers some of this.

    <Norm> scribenick: norm

    <timeless> JS: Suppose that instead of dealing with two different

    timeless: Suppose that instead of two people, you deal with one
    vendor and two installed instances of the same vendor.
    ... So you made the world's greatest clock, but I want to run it
    ... This has to be allowed, some widget engine might not allow it,
    but we expect in the general case that it will be possible.
    ... For these things, the general expectation is that the names are
    local. They're just so that the widget can introspect itself.

    <marcos> widget://widgetEngine/pack.wgt/some/path/to/file

    <marcos> widget://pack.wgt/some/path/to/file.png

    <marcos> widget://{uuid}/path/to/file.png

    <marcos> widget://path/to/file

    timeless: It shouldn't be able to be remotely readable. It's a
    privacy violation if you can see what else is running.

    NM: You could just name them 1, 2, 3, 4,...

    timeless: Without using those particular numbers.

    DanC: Where do widget: get resolved?

    timeless: In the DOM, where .source must be resolvable.
    ... For example, in img.src.

    DanC: No one ever writes these things down?

    timeless: You could, but it won't work.

    NM: I wonder if the thing to choose would be a less-obvious, less
    intrusive name. If you said these things were for people to write
    down, then widget: is simple.
    ... But if you never expect them to be written down, you could pick
    a more obscure name.

    ???: These things might one day appear in other spaces.

    <timeless> ABe: if MC would put dashboard back up

    <scribe> scribenick: timeless

    UNKNOWN_SPEAKER: the only potential i see for this to leak out

    <MikeSmith> browser architecture in general also suggests that
    things leak out (e.g., from XUL into gecko core)

    ABe: is a bizarre use case
    ... as you can see he has two clock instances

    <Zakim> DanC_lap, you wanted to ask where widget: URIs typically

    ABe: The possibility would be if you could package a skin for

    <Zakim> DanC_lap, you wanted to ask about js a la: if img.src =

    MC: as you can see this leaks the full path
    ... the security model of these applications is not equivalent to
    ... per the package resource you must specify which privileges you
    ... e.g. network=true|false
    ... plugins=true|false
    ... and additional features
    ... and we have a seperate policy language to control what is
    actually allowed

    DanC: so you guys are attacking the software installation problem

    MC: yes

    DanC: the slide layout changed for http

    MC: no, i wasn't comparing the protocols against them
    ... I was hoping through the magic of transitions, you'd be
    ... At this point we're open to anything
    ... But we see a lot of problems with http

    DanC: you're certainly changing the software implementation of http

    MC: there are going to be hundreds of things we'd have to say you
    can't do

    with http

    scribe: in terms of defining response codes.

    Noah: to me what's going to be harder
    ... the problem might be that when you do an http request
    ... for some cases you're going to want to do a real http request
    ... and some cases you won't.

    <DanC_lap> (I would use "subtle" where he used complex on the slide,
    but the point is pretty much the same)

    MC: even the overhead of adding the overhead of http is code+weight

    Noah: it's still very light as protocols.

    DanC: did the requirements list the security policy, e.g. same
    origin, details?

    <Norm> scribenick: Norm

    timeless: So, one of the things that widgets will do is ask for
    access to HTTP
    ... So they might call home and do work with their well known
    server, and probably only that server
    ... There's a bugzilla appilication that does caching and it would
    be nice if I could use it for any bugzilla.
    ... It's just a widget I've installed (purchased actually, there's a
    real vendor for this).
    ... It's a bugzilla UI, but it has no relation to the code for the
    standard bugzilla UI
    ... One of the things we've prioritized is "Networked: true or
    ... So it's going to access HTTP, it's going to want to phone home
    or talk to other servers, it's a purchased app that doesn't want to
    be shared

    <MikeSmith> ArtB: ↑

    ABe: Reusing http: introduces ambiguity, is [36]http://widget.com/ a
    pointer into the widget or a pointer to a resource on the "real"
    ... This is especially the case now that TLD has gone away.

      [36] http://widget.com/

    Noah: Is this really a collision? What two things have the same name

    DanC: It's not a collision, it's the same thing, one way is to get
    it from the remote server and the other way is to get it from the

    ABe: Then there's the problem of the signed package.

    <scribe> scribenick: timeless

    Noah: usually a signature is an invariant

    MC: when a signature changes, what do you do then?

    AB: time check

    MC: implementation detail...
    ... (Slide)
    ... hopefully i've proven to you that apple's solution of using file
    is a privacy issue and security risk

    <DanC_lap> (ah... so "implementation detail" doesn't prohibit file:)

    MC: I don't see leaving it as an implentation detail is an actual

    <Zakim> DanC_lap, you wanted to ask about the state of deployment
    and to explore the "implementation defined" proposal (e.g. run-time
    generated nonce scheme name)

    <Norm> DanC: Why not just make up the scheme names on the fly?

    <Norm> timeless: Scheme names can be added on the fly, after the
    application starts to run, so there would be the possibility of

    JS: ok

    MC: we need to consider extensibility of the uri scheme

    Noah: the design considerations are going to be very different in
    two instances

    <DanC_lap> DanC: I'd sure like to hear a consistent answer about
    whether these are internal-only names or not.

    Noah: make a decision about if it leaks out
    ... it feels wrong to design something hoping it doesn't leak out.

    <Norm> JS: One possibility, though not likely, imagine that I make a
    game where you click on the right or the left image.

    <Norm> ...If I store that in a preference (or maybe it's the base
    path of a theme)

    <Norm> ...I strip off just the picture name and I have the name for
    the theme.

    <Norm> ..The working assumption I have is that we could/would allow
    when you install an *instance* of a widget, the scheme could be
    frozen at that point.

    <DanC_lap> "In addition, a conforming specification MUST recommend
    that a widget user agent implement a means to persistently store
    user preferences for each widget instance. " --

      [37] http://dev.w3.org/2006/waf/widgets-reqs/

    <Norm> ...That means I persist the theme base up to the image point.
    I don't ever show it to the user, but I do use it and I do show it
    to the widget engine.

    <Norm> DanC: So that's a pretty clear answer: these aren't just for
    a single, running instance

    <Norm> JS: It's not usefully leaked out to a web server, but it's
    lifetime might be as long as that instance is installed.

    Noah: it seems like you are exposing two things
    ... it seems like you're offering to have a management policy which
    shows groups of related instances

    <Norm> JS: I think personally, the HTML5 has this persistence stuff
    which is new, I don't know what sort of user interface it has.

    <Norm> ...Suppose it's like cookies, users can see related cookies.
    In today's scheme, the logical thing is the domain.

    <Norm> ...As long as the widget user agent stores which widget got
    which random ID, it would be ok.

    <Norm> ...Though it might be easier from an implementation
    perspective to split on the name instead of hashing it.

    <Zakim> DanC_lap, you wanted to ask about guuids in widget: uris

    Danc: is widget:uuid in your current draft

    MC: it was in a draft, it is no longer

    DanC: have you decided in favor/against?

    MC: it's an open issue

    DanC: what's state of the art?

    ABe: Opera 9.6 on desktop and probably base for windows mobile and
    ... probably uses widget and some widgetuseragent generated bit
    ... it's only meaningful for the device
    ... it also establishes a security model for accessing things
    ... as the browser can reuse the cross domain security module
    ... we're using an identifier because it's an incredibly convinently
    way to establish a same origin policy

    DanC: and the fact that it's not easily guessable
    ... if that it's not easily guessable is a requirement
    ... then that rules out domain names.

    ABe: this is based on Opera's internal choices which predate the
    consensus (not yet established)
    ... of the working group

    PB: Even if the unique identifier were guessed, knowing that, no
    widget would have any greater rights
    ... the hard to guess requirement comes from privacy,
    ... number of installed entities.

    <DanC_lap> (I need to remember this bit about security constraints
    that suggest install-time names and talk with timbl about it. my
    brain is not a reliable storage medium now. I wonder if I should
    make a TAG tracker action.)

    MC: the runtime will still block widget accessing other widgets
    because of identifier/origin crossing

    JS: MC "instantiated a new instance of the clock widget"

    ABe: currently that on Opera desktop involves downloading another

    MC: I believe Apple downloads it again

    BS: For windows, there's one on disk image and two memory instances.

    ABe: whether instantiation involves by copying on disk or not is an
    implementation detail
    ... which doesn't affect the discussion at any point.

    MC: TAG: do you feel we have enough grounds for a new uri scheme?
    ... if not, what do we need to do?

    DanC: you need to establish the right requirements

    AB: I agree we need to flesh out the requirements
    ... I think they're in the points MC listed but not fleshed out

    <DanC_lap> (ArtB, is that in the requirements document?)

    Noah: I think you need to establish for all time whether things leak

    JS: requirements doc is [38]http://dev.w3.org/2006/waf/widgets-reqs/

      [38] http://dev.w3.org/2006/waf/widgets-reqs/


      [39] http://dev.w3.org/2006/waf/widgets-reqs/#r36.-

    Noah: if you think they're going to leak out....
    ... I would really look at the registry issues.

    <Norm> NW: My position is roughly in line with Noah's. If you're
    going to allow these things to leak out, or if it's going to be
    valuable to share them, then I think the logical thing to do would
    be to use http: URIs in that case.

    <Norm> ...And if you do that, I'd be highly motivated to see if it's
    possible to use http: for all the names so that you don't need to

    MC: is there a precedent for a readonly server

    DanC: i think debian package names

    <DanC_lap> (debian package names are, in a way, grounded in http

    MC: has someone written a spec which defined using readonly

    DanC: TimBL asked the python people to make python package names
    into http uris

    Noah: has anyone gone to the browser people
    ... to make a complicated proxy hack for http

    MC: hsivonen of mozilla explained that it would be hard and cause

    AB: where do we do follow up? www-tag?

    DanC: yes
    ... what's the time scale?

    MC: we want to finish this within 3 months.

    DanC: are there any test cases for this?

    MC: no
    ... we're starting an implementation now

    AB: coffee break

    <DanC_lap> (I might have some more precedent bookmarked under
    "software installation" on delicious; network isn't happy. :-/)

    <hlee7> hello

    <ArtB> Chair: ArtB

    <marcos> chairnick: Artb

    <marcos> chair: Artb

Section 8.2, Step #11 - Need to describe what happens if the widget
already exists

    <ArtB> AB: [40]http://dev.w3.org/2006/waf/widgets/#step-11

      [40] http://dev.w3.org/2006/waf/widgets/#step-11

    <ArtB> AB: if widget already exists, what do we do?

    <ArtB> ABe: what do other impls do?

    <ArtB> MC: Dashboard says "widget exists, do you want to override

    <ArtB> JS: not sure I understand why this is in Step 11

    <ArtB> MC: agree, it's not really related to Step 11

    <ArtB> ... but the issue needs to be addressed

    <ArtB> JS: so the same widget cannot be installed more than once?

    <ArtB> MC: that's correct

    <ArtB> BS: is this based on file name?

    <ArtB> MC: no it isn't

    <ArtB> ... it is based on something internal

    <ArtB> ABe: probably some id

    <ArtB> ABe: this should probably be an impl detail

    <ArtB> BS: not sure I agree

    <ArtB> ... for Vista, it's based on file name

    <ArtB> MC: On Dashboard, uses identifier in the plist file

    <ArtB> AB: I tend to agree this should be an implementation detail

    <ArtB> ... Let the UA decide what to do

    <ArtB> ... Could also reflect a user preference

    <ArtB> [ Marcos does some experimenting with Dashboard ... ]

    <hendry> Opera 9.6 allows the same widget to be installed multiple

    <ArtB> MC: either it is an impl detail or we specify it :-)

    <ArtB> MC: we need to specify something regarding update

    <ArtB> ... versus installing a second widget with the same name/id
    as a previously installed widget

    <ArtB> MC: part of the problem is that the config file is optional

    <ArtB> PB: such a widget can never be considered identical to
    another widget

    <ArtB> [ Marcos enumerates the various scenarios ]

    <ArtB> ... 1. If no config file, they are treated as unique

    <ArtB> ... 2. If config file, but no id attr, then they are treated
    as unique

    <ArtB> ... 3. If config has an id attr, and id is the same on both,
    they are the same widget

    <ArtB> see update spec)

    <ArtB> ... 4. If config has an id attr and a version attr that is
    diff from the current installed version, then it is an update

    <ArtB> ... per the Updates spec

    <paddy> MIDP spec relating to ugrade procedure:

      [41] http://jcp.org/en/jsr/detail?id=118

    <hendry> apt-get remove --purge package && apt-get install package

    <hendry> (how Debian works)

    <ArtB> JS: users don't want to have any of their data removed during

    <ArtB> ... can always do some data pruning after the update is

    <ArtB> PB: Java have some conventions we can consider

    <ArtB> MC: we've discussed comparing versions before

    <ArtB> JS: can also take a look at what Mozilla has done

    <ArtB> ... the application decides what to do

    <hendry> debian version ref:

      [42] http://www.debian.org/doc/debian-policy/ch- 

    <ArtB> MC: I've already looked at some various practices

    <ArtB> ... We could recommend a rollback mechanism

    <ArtB> [ Marcos displays MIDP 2.0's versioning mechanism ... ]

    <ArtB> MC: is 1.02 < or > than 1.002?

    <ArtB> PB: can't do 1.002

    06.html old version string discussion

      [43] http://lists.w3.org/Archives/Public/public-appformats/ 

    <ArtB> ... limited to two decimals per number

    <ArtB> ABe: what about one widget with more than one branding?

    <ArtB> AB: I don't think we are getting consensus on this issue

    <ArtB> MC: propose we leave the current model but recommend using
    MIDP model

    <ArtB> PB: besides version number, we still have the original issue

    <ArtB> MC: propose we recommend authors use MIDP model for

    for the record,

      [44] http://archive.ubuntu.com/ubuntu/pool/multiverse/f/ 

    <ArtB> ACTION: Marcos will create the text and processing model to
    codify the four conditions enumerated above [recorded in

    <trackbot> Created ACTION-271 - Will create the text and processing
    model to codify the four conditions enumerated above [on Marcos
    Caceres - due 2008-10-27].

    <ArtB> ACTION: Marcos will create text to address the version string
    issue by recommending MIDP 2.0 model [recorded in

    <trackbot> Created ACTION-272 - Will create text to address the
    version string issue by recommending MIDP 2.0 model [on Marcos
    Caceres - due 2008-10-27].

    <ArtB> AB: We do need to careful about copyright issues

    <ArtB> MC: I will create text that is "inspired by" the Java doc but
    will not copy it

Section 9.1 locating thumbnails

    <ArtB> MC: it is a duplicate of the finding the icons issue

    <ArtB> ... We don't need to discuss it

    <ArtB> AB: Meeting Adjourned for today

Summary of Action Items

    [NEW] ACTION: Barstow determine the status of URI Template RFC and
    report back to WG [recorded in
    [NEW] ACTION: Barstow see if the W3C systeam/webreq can help with a
    conformance checker [recorded in
    [NEW] ACTION: Macros move the version string section from P&C spec
    to the Updates spec [recorded in
    [NEW] ACTION: Marcos move the version string section from P&C spec
    to the Updates spec [recorded in
    [NEW] ACTION: Marcos send Widget URI scheme slides to one of
    {member,public}-webapps [recorded in
    [NEW] ACTION: Marcos will create text to address the version string
    issue by recommending MIDP 2.0 model [recorded in
    [NEW] ACTION: Marcos will create the text and processing model to
    codify the four conditions enumerated above [recorded in

    [End of minutes]
      [59] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Tuesday, 21 October 2008 20:40:59 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:12 UTC