W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

[widgets] Minutes of 26 August 2008 Widgets f2f meeting

From: Arthur Barstow <art.barstow@nokia.com>
Date: Sat, 30 Aug 2008 09:13:44 -0400
Message-Id: <FF3BC513-B7D6-4C15-91D2-FC6F981315DB@nokia.com>
To: public-webapps <public-webapps@w3.org>

The minutes from the August 26 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 September 11 (next  
Widgets voice conference); otherwise these minutes will be considered  

-Regards, Art Barstow


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

                                - DRAFT -

                           Widgets F2F Meeting
                               26 Aug 2008


       [2] http://www.w3.org/2006/appformats/group/TurinF2F

    See also: [3]IRC log

       [3] http://www.w3.org/2008/08/26-wam-irc


           Art_Barstow, Marcos_Caceres, Mark_Priestly, David_Rogers,
           Fabio_Ricciato, Luca_Bruera, Benoit_Suzzane, Marco_Bartolini,
           Maruo_Sacco, Paddy_Byers, Thomas_Landspurg, Claudio_Venezia,
           Josh_Soref, Arve_Bersvendsen, Nick_Allot




      * [4]Topics
          1. [5]Introduction
          2. [6]Agenda Review
          3. [7]Last Call of Requirements Doc
          4. [8]Disposition of Comments document for the Requirement
             Last Call
          5. [9]Configuration and Packing Spec
          6. [10]ZIP Archive
          7. [11]Issue #16 - Do widgets need their own URI scheme?
          8. [12]URI Scheme and Query parameter
          9. [13]URI Scheme and Encoding
         10. [14]P&C Issues
         11. [15]Issue #34 - What happens when one runs out of storage
             space when decompressing a widget?
         12. [16]Issue #46 - Need to define a <span> for i18n purposes
             in configuration document
         13. [17]Issue #20 - Current <content> model does not allow
             multiple views
         14. [18]Issue #21 - should Widgets 1.0 allow fallback for
             <content> element?
         15. [19]Webwag presentation
      * [20]Summary of Action Items

    Date: 26 August 2008

    <scribe> Scribe: Art

    <scribe> ScribeNick: ArtB


    <claudio> Fabio Ricciato

Agenda Review

    <MikeSmith> ArtB: if you have the phone set up, can you please call
    1.617.761.6200 with code 26632 ?

    AB: any change requests for the agenda

    Josh: I won't be here on Thursday

    Arve: I need to leave early Thursday
    ... want to push APIs to Wednesday

    AB: any other change requests?


Last Call of Requirements Doc

    AB: anything from Kryztof we want to discuss?

    MC: no; I will respond to his comments by end of next week

    AB: I18N is done, right?

    MC: yes

    AB: Josh submitted some comments at the end of last week

    MC: yes mostly editorial comments but 1-2 issues

    AB: Josh submitted two e-mails:
    ... 1.
    ... 2.
    ... one issue is about proxies and we already identified that as an
    issue (#17)

      [21] http://lists.w3.org/Archives/Public/public-webapps/ 
      [22] http://lists.w3.org/Archives/Public/public-webapps/ 

    MC: we decided the proxy used by an instance of a widget is an impl

    JS: there is also an issue about the proxy and a signature

    ABe: but we are signing the uncompressed files
    ... agree proxy is an implemenation detail

    MC: we removed the requirement an end user can specify the proxy
    ... since that is an implementation detail

    BS: so what will the spec say?

    MC: we no longer have a related requirement
    ... We could have an informative note about it
    ... we are saying that if a Widget instance wants to use a specific
    proxy that's OK but we don't need our spec to saying anything
    Normative about this

    AB: proposed Resolution: Issue #17 is Closed - this is an
    implementation detail for Widget User Agents; we may add an
    Informative note in one of the specs
    ... any objections?

    <arve> none


    RESOLUTION: Issue #17 is Closed - this is an implementation detail
    for Widget User Agents; we may add an Informative note in one of the

    <scribe> ACTION: Barstow close Issue #17 [recorded in

    <trackbot> Created ACTION-218 - Close Issue #17 [on Arthur Barstow -
    due 2008-09-02].

    AB: are there any other comments in Josh's first email we want to

    JS: no; but let's look at my 2nd email

    <timeless> R40. Automatic Updates

    <timeless> what happens if i have 3 instances of a widget? do they
    all get upgraded?

    JS: the other issue is what happens when 3 instances of one widget
    are installed - what happens during auto-update?

    <Benoit> they should...

    ABe: I think this should be an impl detail

    MC: I think all 3 should get updated

    ABe: I don't think we should be overly prescriptive here
    ... don't want to have to add a bunch of APIs to support this

    JS: < reads Req #40 >

    MC: I think we need to be flexible here

    BS: could say the user should be able to check (when there are
    multiple instances installed)

    AB: there is also the scenario of a device having more than one
    Widget UA

    <arve> ABe: Could we add an informative note that a UA MAY treat two
    installations of a widget from a source URI as either two different
    widgets, or as two instances of one widget

    AB: propose new Issue: should text about auto-updates regarding
    multiple instances of installed widgets be Informative or Normative?
    ... anyone object to this issue being addressed by Informative text?

    MC: I object
    ... I don't think we should mention it at this point
    ... if Benoit or someone else provides some text, I can add it to
    the auto updates spec

    <Benoit> ok to take it out

    AB: propose Resolution: the reqs doc will be silent on auto-updates
    and multiple instances
    ... any disagreements


    RESOLUTION: the reqs doc will be silent on auto-updates and multiple
    instances (but some Informative text may be added to the auto-update

    AB: any other comments Josh?

    JS: not to discuss now

    MC: Marcos, can you commit to responding to Josh's two email by the
    end of next week?
    ... yes

    <scribe> ACTION: Marcos respond to Josh Soref's two e-mail comments
    by Sept 5 [recorded in

    <trackbot> Created ACTION-219 - Respond to Josh Soref's two e-mail
    comments by Sept 5 [on Marcos Caceres - due 2008-09-02].

Disposition of Comments document for the Requirement Last Call

    ... unfortunately this is a Member-only link
    ... I don't like this

      [25] http://www.w3.org/2006/02/lc-comments-tracker/42538/WD- 

    MC: it's because some of the WG's responses could include
    Member-confidential info

    AB: what's the status?

    MC: it contains everything but: 1) Krzystof's comments; 2) Josh'
    latest two e-mails

    AB: good

    MC: re issue LC-1983 from Josh, Issue #1 is "should we mandate that
    developers and admins be allowed to

    install their own certs?"

    MP: this is related to req #38
    ... I submitted some comments about this to the mail list
    ... and proposed new text

    AB: has this been addressed in the Editor's Draft?

    MC: no; waiting for more input

    ABe: I think the most we can specify here is a MAY

    MC: this can be viewed as in impl detail of the Widget UA

    MP: I agree it should be impl-specific

    <timeless> propose Could the digital signature specification have an
    informative note that widget authors should not expect to be able to
    sign widgets using certificates which are not chained to well known
    public roots.

    MP: but we don't want it to break the security model
    ... If the requirement was removed from the Reqs doc that is OK
    ... from VF's perspective, we could remove it

    MC: I propose "Additional Digital Certificates" (Issue #38 in the LC
    doc) be removed from the Reqs and it becomes an Informative note in
    the DigSig spec

    AB: any comments or objections to Marcos' proposal?


    RESOLUTION: Additional Digital Certificates" (Issue #38 in the LC
    doc) be removed from the Reqs and it becomes an Informative note in
    the DigSig spec

    AB: what about the comments submitted by Frederick Hirsch (Chair of
    the XML Security WG) submitted on August 25?

    MC: we have already addressed his comments
    ... they were both Editorial
    ... I will add his comments to the LC Disposition of Comments doc

    AB: with the possible exception of Krzystof's comments and our
    responses raising some new Issues, I think we're mostly OK with the
    comments we received re the LC Reqs doc

    MC: I will need to address the URI and IRI references correctly
    ... it would be good to get a URI expert to review my changes

    AB: any other comments we need to discuss?

    MC: some of Krzystof's comments are a bit academic
    ... but again, I will respond to all of his comments

Configuration and Packing Spec

    <barstow> AB: we have Issues identified in the Editor's Draft

    <barstow> ... as well as Issues defined in our Action and Issue DB

      [26] http://www.w3.org/2008/webapps/track/

    <barstow> ... Marcos, what is your preference for reviewing these

    <barstow> MC: let's first look at the issues in the latest ED

    <barstow> ... I made an update during my flight from Brisbane

    <barstow> ... I will upload it now ...

    <barstow> AB: latest Editor's Draft is

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

ZIP Archive

    <barstow> MC: we are restricted to the limits of ZIP as implemented
    and deployed today

    <barstow> ... UTF-8 now supported in ZIP format

    <barstow> ... can also now explicitly add an encoding

    <barstow> MC: a question for us - which version of ZIP do we want to

    <claudio> is conference 26632 expired? I cannot dial in...

    <MikeSmith> claudio: yeah

    <barstow> ... supporting the latest version of ZIP could add some
    additional problems and/or complexity

    <MikeSmith> claudio: please use 26631

    <barstow> MC: the motion is "we only support UTF-8 encoded file

    <claudio> ok we're in

    <barstow> AB: what happens if we make this a firm requirement
    regading existing impls?

    <barstow> MC: I think Apple will fail

    <barstow> ... when Dashboard widget is un-zipped on a Windows system

    <barstow> MC: we don't have to add other encoding now; they can be
    added later i.e. in a subsequent version of the spec

    <barstow> ABe: I think what we have currently spec'ed is OK

    <barstow> AB: version of ZIP do we now support is what, Marcos?

    <barstow> MC: 6.3

    <barstow> ABe: frankly, we need an open spec for ZIP

    <barstow> ... we shouldn't be blocked by PKWare

    <barstow> MC: ISO is working on such a spec now

    <Ralph> you folks have two teleconferences running and 1 person on

    <Ralph> I will attempt to move the person on the first teleconf to

    <barstow> MC: the motion is "UTF-8 and CP437" support

    <barstow> MC: the I18N WG recommended this change

    <barstow> ...

      [28] http://www.w3.org/mid/ 

    <barstow> MC: I propose step #8 of the ZIP Archive Verification step
    be left as is and we would not accept the change proposed by the
    I18N WG

    <barstow> AB: any objections to Marcos' propsosal?

    <barstow> [None]

    <barstow> RESOLUTION: step #8 of the ZIP Archive Verification step
    be left as is and we would not accept the change proposed by the
    I18N WG

    <barstow> JS: should we explain why?

    <barstow> MC: I already stated rationale in my response to Addison:

      [29] http://www.w3.org/mid/ 

Issue #16 - Do widgets need their own URI scheme?

    <barstow> AB: issue is:

      [30] http://www.w3.org/2008/webapps/track/issues/16

    <barstow> MC: Tim Berners-Lee and some other members of the TAG have
    suggested we use http: scheme

    <barstow> ... and we should not mint/create a new scheme

    <barstow> MC: the UUID part of the grammar is a "straw man"

    <barstow> TL: why not use a relative path?

    <barstow> MC: in the DOM must have an absolute path

    <barstow> TL: but an author of a Widget just needs to know relative

    <barstow> JS: but on different platforms, relative paths could be
    treated differently

    <barstow> MC: widget developers are heavily discouraged from ever
    using absolute URIs

    <barstow> ABe: the author can't predict the domain part of the URI
    (expect some type of UUID)

    <barstow> AB: besides Tim, Stuart Williams and Roy Fielding (also on
    the TAG) also raised some concerns about the widgets: scheme

    <barstow> ... Roy:

      [31] http://lists.w3.org/Archives/Public/www-tag/2008Aug/0066.html

    <barstow> AB: regarding the process, when the spec is ready to go to
    Candidate, if this issue is still Open, we will need to convince W3C
    Management the WG made the right decision to ignore this feedback

    <barstow> MC: query strings are another part of the scheme that is
    an open issue

    <barstow> MC: do we want to support POST?

    <barstow> MC: I think Roy is over complicating the issue

    <barstow> JS: Roy recommends "cid" scheme

    <barstow> ... has anyone looked at it?

    <barstow> ... At a minimum, we should look at it and respond

    <barstow> JS: If you look at Roy's first statement, I think he's

    <barstow> AB: perhaps he doesn't clearly understand our use case;
    seems like he is thinking about "web widgets"

    <barstow> MC: our use case is taking files and put them in a ZIP

    <barstow> TL: not sure it's good to make a differentiation between
    WebApps Widgets and "Web Widgets"

    <barstow> MC: our approach is that a single file is transferred and
    transfer can come over Bluetooth, Infra-red, etc. but it doesn't
    necessarily need to be HTTP

    <barstow> ABe: I agree there may be some work we can do to better
    define our use case

    <barstow> TL: why not use "file"?

    <barstow> JS: because file: has some issues e.g. security

    <barstow> ABe: Widget authors could easily abuse file: and do some
    very bad things

    <barstow> MC: the widget: scheme is supposed to create a sandbox

    <barstow> TL: so we just want the Widget to only be able to access
    its own resources

    <barstow> JS: cid: doesn't appear to be appropriate

    <barstow> ... because it requires MIME support

    <timeless> [32]http://www.w3.org/Addressing/URL/4_1_Cid.html

      [32] http://www.w3.org/Addressing/URL/4_1_Cid.html

    <barstow> NA: the widgets scheme gives a security box, right?

    <barstow> MC: yes, but some privacy too

    <barstow> JS: the Widget UA needs to be able to expose to the Widget
    a unique resource that is related to itself (and nothing else)

    <barstow> [We pause and look at R6:
    Addressing Scheme and then continue discussion]

      [33] http://dev.w3.org/2006/waf/widgets-reqs/#r6.-addressing

    <barstow> JS: perhaps the requirement needs some additional text re

    <barstow> NA: I think there are some security aspects of the widget:
    scheme that are implied and perhaps should be more explicit

    <barstow> ... perhaps the use cases need to be expanded


      [34] http://lists.w3.org/Archives/Public/public-webapps/ 

    <barstow> CV: Stuart Williams asked for additional use case

    <barstow> CV: Stuart also asked about widget to widget communication

    <barstow> MC: HTML5 is addressing document to document communication
    and presumably Widgets could leverage that mechanism

    <barstow> ABe: I think using our own widget: scheme will help reduce
    security risks

    <barstow> AB: so where does this leave us?

    <barstow> MC: we need to clarify the model; it is based on the "old
    timers" in the WG

    <barstow> ... I can clarify the text and address any ambiguities

    <barstow> MC: we will have to continue discussions with the TAG

    <barstow> ... I suspect they may have not actually read our spec
    thoroughly and don't understand our use cases

    <barstow> BS: perhaps we can invite them to one of our voice confs

    <barstow> AB: we can meet with them f2f in Mandelieu

    <barstow> MC: I think we are doing the right thing and agree we need
    to continue to engage with them

    <barstow> AB: I can invite Stuart and the TAG to one of our voice

    <barstow> ... I think it would be helpful to first expand on our Use
    cases and Rationale

    <barstow> TL: still think the distinction between Widgets and Web
    Widgets is causing confusing

    <barstow> ABe: don't think of Widgets as web pages but a collection
    of resources that can be packaged and installed

    <barstow> MC: I think the Web widget model and Webwag widgets are a
    different model; perhaps we'll get there in v2

    <barstow> ABe: the widget: scheme will allow browsers to reuse their
    security model (sandbox)

    <barstow> ACTION: soref respond to Roy Fielding's email regarding
    the widget scheme and his proposal to use cid: [recorded in

    <trackbot> Created ACTION-220 - Respond to Roy Fielding's email
    regarding the widget scheme and his proposal to use cid: [on Josh
    Soref - due 2008-09-02].

    <barstow> AB: do we need more motivational text?

    <barstow> MC: I think we have already responded well enough

    <barstow> ... I don't think the requirement needs to be updated

    <barstow> AB: do you want me to invite Stuart and/or the TAG to our
    voice conf?

    <barstow> MC: not yet; let

    <barstow> ... us wait until Roy responds to Josh's e-mail

URI Scheme and Query parameter

    <marcos> [36]http://dev.w3.org/2006/waf/widgets/Overview.src.html

      [36] http://dev.w3.org/2006/waf/widgets/Overview.src.html

    <barstow> [ the network is not capable of delivering the entire
    Editor Draft of the latest P&C spec thus I cannot add the text
    Marcos created re the URI query ... ]

    <marcos> MC: how do we resolve: <content src="index#1.html?foo=bar">

    <barstow> AB: does this need to addressed for v1?

    <barstow> MC: yes, I think so

    <barstow> ABe: I think the example is a bit of an edge case

    <barstow> AB: if we say query strings aren't allowed, what breaks?

    <barstow> ABe: I tried your example in a couple of different
    browsers and they yield different results

    <barstow> ... The question isn't about forbid vs. not forbid, but if
    query string should be supported

    <barstow> MC: once we hit the "#" we don't say what happens

    <barstow> ABe: one of the two user agents I tried has a bug; we
    should clarify in the spec

    <barstow> MC: we should just say the value of the src attr is a URI

    <barstow> ... I will also need to update the definition of the IRI

    <barstow> [ Marcos adds text to his latest ED that describes the
    results of our discussion: we don't chop stuff off the end but we
    don't interpret it either ]

URI Scheme and Encoding

    <barstow> MC: need to add text about the encoding

    <barstow> ABe: I would expect a UA to map any CP437 chars to UTF-8

    <barstow> ABe: we could say anything outside of US-ASCII must be

    <scribe> Scribe: Art

    <scribe> ScribeNick: ArtB

P&C Issues

    AB: agenda: [37]http://www.w3.org/2006/appformats/group/TurinF2F
    ... I'm indifferent as to the order we discuss the issues

      [37] http://www.w3.org/2006/appformats/group/TurinF2F

Issue #34 - What happens when one runs out of storage space when
decompressing a widget?

    AB: issue #34 - [38]http://www.w3.org/2008/webapps/track/issues/34

      [38] http://www.w3.org/2008/webapps/track/issues/34

    MC: we discussed this in IRC a week or two ago
    ... we being me and Arve

    ABe: I think this is an impl detail and a fatal error

    JS: I want this to be a fatal error
    ... I don't think a UA should limp along
    ... if it can't handle all of the files

    ABe: if a UA canNOT represent all resources in the package, it must
    be a fatal error

    JS: a UA could tell the user if there aren't enough resources and
    ask them to remove/stop something

    AB: I'm not convinced we need to address this question

    JS: there is no guarantee the user can be given a message before it

    AB: what would we need to specify and in what spec would we address

    MC: we could say something in the P&C spec but probably nothing
    ... in the extraction phase, the Widget UA should stop the widget
    ... if there is a storage failure

    AB: does anyone think this issue is important enough to submit an
    input to address the issue?


    AB: I propose we close this issue and say we will consider it for v2
    ... any objections?

    ABe: I don't think this issue should be handled by a spec
    ... but could be covered in some type of informational doc

    RESOLUTION: we will close this issue for now (not critical) and we
    may consider it in the future

    <scribe> ACTION: Barstow close Issue #34 with resolution above
    [recorded in

    <trackbot> Created ACTION-221 - Close Issue #34 with resolution
    above [on Arthur Barstow - due 2008-09-02].

Issue #46 - Need to define a <span> for i18n purposes in configuration

    AB: issue is [40]http://www.w3.org/2008/webapps/track/issues/46

      [40] http://www.w3.org/2008/webapps/track/issues/46

    MC: the issue is that part of the widget should be author-able with
    Right-to-Left and other parts Left-to-Right
    ... the proposal is a <span> element like the one in HTML

    ABe: so this would mean the description element can support more
    than one span element?

    AB: do any web browsers support this requirement?

    MC: yes

    ABe: how do I handle different descriptions?

    MC: put each description in a different file

    ABe: what attributes would be placed on <span>

    MC: probably just direction

    BS: why do we need <span> if localized text is placed in localized

    MC: because authors may want to use both directions in a single

    AB: Marcos, you will spec the span element with just the one
    direction element?

    MC: yes; plus need to change the parsing model

    AB: I'm wondering about the burden to the UA

    Marcos: ask I18N WG if Unicode RTL is sufficiently supported in UAs;
    if not we will include the <span> element in the Widgets spec

    JS: HTML5 has a <bdo> element we should consider

    ABe: I think we need some more solid research

Issue #20 - Current <content> model does not allow multiple views

    AB: issue is: [41]http://www.w3.org/2008/webapps/track/issues/20

      [41] http://www.w3.org/2008/webapps/track/issues/20

    [ Marcos demonstrates the issue by showing a Dashboard Clock widget
    as one instance and the Digital Clock "text" at the top tool bar ]

    PB: in Java can have one application that has two different running
    instances - each with a different view e.g. presenation

    MC: in the mobile world a single clock widget could take up the
    entire screen or just be a small piece on the idle screen

    ABe: I don't want to have multiple content elements but perhaps
    provide APIs to control views

    JS: on S60 the idle screen apps cannot accept any input so they
    aren't really views in this context
    ... an app can change modes e.g. full to small
    ... icons and notifications are covered elsewhere
    ... I think the answer to "can we have multiple <content> elements?"
    is no

    BS: we need a way to suppport two different views but those two
    views do not need to be displayable at the same time
    ... I think that can be done with APIs rather than <content>

    ABe: we support rendering widgets in different "modes"
    ... with or without chrome and full screen and "dock mode"
    ... a problem with multiple content elements is how the instances
    communicate with each other

    AB: I propose we close this issue now and put it in on the "consider
    for v2 list"

    MC: I agree with that

    AB: any objections?


    RESOLUTION: Issue #20 will be closed and this feature will be added
    to the v2 Feature List

    <scribe> ACTION: Barstow close Issue #20 with the resolution above
    [recorded in

    <trackbot> Created ACTION-222 - Close Issue #20 with the resolution
    above [on Arthur Barstow - due 2008-09-02].

Issue #21 - should Widgets 1.0 allow fallback for <content> element?

    AB: issue is: [43]http://www.w3.org/2008/webapps/track/issues/21

      [43] http://www.w3.org/2008/webapps/track/issues/21

    MC: some vendors have requested this feature

    ABe: technically speaking, I don't think this is difficult to
    ... but I do think some vendors with proprietary HTML extensions
    won't work very well
    ... I think this could be abused to make the default be an "upgrade
    here" message

    CV: is this the same question as what a UA should do if an API isn't

    MC: no, I see it as different but related

    BS: can we push this to v2?

    MC: unless some vendor says it is mandatory for v1, I think we can
    push it to v2

    AB: propose closing Issue #21 and add it to the v2 Feature List
    ... any objections?


    RESOLUTION: Issue #21 is closed and will be added to the v2 Feature

    <scribe> ACTION: Barstow close Issue #21 with the resolution above
    [recorded in

    <trackbot> Created ACTION-223 - Close Issue #21 with the resolution
    above [on Arthur Barstow - due 2008-09-02].

Webwag presentation

    <claudio> mission: providing means for accessing digital contents
    from everywhere via mobile

    <claudio> WW definition of widget synthesize in single view lots of

    <claudio> WW is multiplatform, multidevice

    <claudio> WW philosophy about Widget multidevice support: "smooth
    porting" rather than "write once/run everywhere"

    <claudio> WW would like to support W3C spec as far as possible

    <claudio> MC: will widgets be bound to server side for long time?

    <claudio> WW: the installed widget mode might not scale...

    <claudio> MC: deciding the balance between client and server is up
    to Widget implementors

    <claudio> Arve: installed widget are more reliable in terms of
    security (signature)

    AB: Meeting Closed

Summary of Action Items

    [NEW] ACTION: Barstow close Issue #17 [recorded in
    [NEW] ACTION: Barstow close Issue #20 with the resolution above
    [recorded in
    [NEW] ACTION: Barstow close Issue #21 with the resolution above
    [recorded in
    [NEW] ACTION: Barstow close Issue #34 with resolution above
    [recorded in
    [NEW] ACTION: Marcos respond to Josh Soref's two e-mail comments by
    Sept 5 [recorded in
    [NEW] ACTION: soref respond to Roy Fielding's email regarding the
    widget scheme and his proposal to use cid: [recorded in

    [End of minutes]
Received on Saturday, 30 August 2008 13:14:47 UTC

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