W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

[widgets] Draft Minutes from 30 April 2009 Voice Conference

From: Arthur Barstow <art.barstow@nokia.com>
Date: Thu, 30 Apr 2009 10:47:03 -0400
Message-Id: <C23367CF-3B93-4894-A2D6-2C8F2FE9AD1A@nokia.com>
To: public-webapps <public-webapps@w3.org>
The draft minutes from the April 30 Widgets voice conference are  
available at the following and copied below:

    <http://www.w3.org/2009/04/30-wam-minutes.html>

WG Members - if you have any comments, corrections, etc., please  
sendthem to the public-webapps mail list before 7 May 2009 (the next  
Widgets voice conference); otherwise these minutes will be considered  
Approved.

-Regards, Art Barstow

    [1]W3C

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

                                - DRAFT -

                        Widgets Voice Conference

30 Apr 2009

    [2]Agenda

       [2] http://lists.w3.org/Archives/Public/public-webapps/ 
2009AprJun/0405.html

    See also: [3]IRC log

       [3] http://www.w3.org/2009/04/30-wam-irc

Attendees

    Present
           Art, Mike, Robin, Marcin, AndyB, Frederick, Marcos, Arve,
           Bryan, Thomas

    Regrets
           AndySledd, Mark, David

    Chair
           Art

    Scribe
           Art

Contents

      * [4]Topics
          1. [5]Review and tweak agenda
          2. [6]P&C spec: <access> element comments from David
          3. [7]P&C spec: L10N model
          4. [8]Security related issues with "core" Widgets specs (from
             Thomas):
          5. [9]A&E spec: Per-instance Storage discussion
          6. [10]A&E spec: Comments from Rainer:
          7. [11]A&E spec: What needs to be done before publishing a
             LCWD?
          8. [12]Widget URI Scheme
      * [13]Summary of Action Items
      _________________________________________________________



    <Marcos_> fjh: none is here yet, call has not started

    <darobin> I'm getting "is unavailable, please try your call later"!

    <scribe> ScribeNick: ArtB

    <scribe> Scribe: Art

    <tlr> I'll be late

    <tlr> other call running over

    Date: 30 April 2009

Review and tweak agenda

    AB: draft agenda submitted 29 April
    ([14]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0
    405.html). Since then Robin requested some additions
    ([15]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0
    438.html) and we will add those agenda items. Any other change
    requests?

      [14] http://lists.w3.org/Archives/Public/public-webapps/ 
2009AprJun/0405.html).
      [15] http://lists.w3.org/Archives/Public/public-webapps/ 
2009AprJun/0438.html)

    [ None ]

    Topics: Announcements

    AB: June 9-11 f2f meeting is just 5 weeks away; please remember to
    register
    ([16]http://www.w3.org/2002/09/wbs/42538/WidgetsLondonJune2009/).
    Any other short annoucements?

      [16] http://www.w3.org/2002/09/wbs/42538/WidgetsLondonJune2009/).

    [ None ]

P&C spec: <access> element comments from David

    AB: on April 23 David submitted some comments regarding the <access>
    element
    ([17]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0
    291.html). I haven't seen a reply. I think the gist of the comments
    is that the spec is a bit under-specified regarding what the UA will
    do with the information. Comments?
    ... David isn't present

      [17] http://lists.w3.org/Archives/Public/public-webapps/ 
2009AprJun/0291.html).

    RB: most comments are fine; I need to coordinate the text with MC
    and that should be it

    AB: I agree they seemed to make sense; think a NOT is missing in the
    4th bullet

    RB: I think the idea is the security policy takes precedence over
    the contents of the access element

    AB: so RB and MC will add text to the ED, right?

    RB: yes

    BS: I have some questions about the access element
    ... the way it is described; uses IRIs
    ... is this limited to HTTP only?
    ... what about other schemes such as FTP or UDP

    RB: any scheme that uses URIs

    BS: this element affects netwwork access by any method
    ... regardless of the scheme

    RB: yes, good point

    AB: do you understands BS' issues well enough to relfect them in the
    spec?

    RB: yes

    AB: anything else on this topic?

    BS: I will send an email about this element to the list

    AB: can you take an action to do that by May 4 at the latest?

    BS: yes

    <scribe> ACTION: bryan submit an email to public-webapps re the
    <access> element [recorded in
    [18]http://www.w3.org/2009/04/30-wam-minutes.html#action01]

P&C spec: L10N model

    <darobin> ACTION: Robin to edit access to take into account OMTP
    feedback and Bryan's [recorded in
    [19]http://www.w3.org/2009/04/30-wam-minutes.html#action02]

    AB: last week Marcos provided a short introduction to L10N model he
    proposed ([20]http://dev.w3.org/cvsweb/2006/waf/widgets/i18n.htm),
    including his preferences for various proposals. Although some of us
    asked for Use Cases and Requirements to substantiate and clarify the
    proposals, they have not been provided. So far, preferences for the
    proposals have been submitted by at least Robin
    ([21]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0
    409.html), AndyS (h

      [20] http://dev.w3.org/cvsweb/2006/waf/widgets/i18n.htm)
      [21] http://lists.w3.org/Archives/Public/public-webapps/ 
2009AprJun/0409.html)

    So far, preferences for the proposals have been submitted by at
    least Robin
    ([22]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0
    409.html), AndyS
    ([23]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0
    436.html), Francois
    ([24]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0
    350.html) and myself
    ([25]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0
    269.html).

      [22] http://lists.w3.org/Archives/Public/public-webapps/ 
2009AprJun/0409.html)
      [23] http://lists.w3.org/Archives/Public/public-webapps/ 
2009AprJun/0436.html)
      [24] http://lists.w3.org/Archives/Public/public-webapps/ 
2009AprJun/0350.html)
      [25] http://lists.w3.org/Archives/Public/public-webapps/ 
2009AprJun/0269.html).

    AB: A1 vs A2; most people prefer A2
    ... any objections to A2?

    [ None ]

    AB: B proposals; 3 for B1 and 2 for B2
    ... what are the benefits of B1, Marcos, briefly?

    MC: support the use case where people speak more than one language
    ... or more than one dialect of a language

    RB: it also models HTTP's lang support

    AB: any objections to B1?

    [ None ]

    RESOLUTION: L10N proposal A2 is agreed
    ... L10N proposal B1 is agreed

    AB: C proposals; there were 2 votes for C1 and Francois preferred C3
    but qualified that
    ... MC, what is you take on this?

    MC: my new pref is for C3, no longer C1
    ... Francois' response convinced me
    ... or perhaps a modfied version of C3

    AB: any other comments?

    RB: I'm fine with C3

    AB: any objection to agreeing on C3?

    [ None ]

    RESOLUTION: L10 proposal C3 is agreed with a few minor mods

    AB: next is the D set of proposals
    ... we have 3 votes for D2 and no other preferences were submitted
    ... any comments about the D set of proposals?
    ... hearing none. Any objections to agreeing on D2?

    [ None ]

    RESOLUTION: L10N proposal D2 is agreed

    AB: the E proposals
    ... MC prefers E1; Robin doesn't like either; Francois says E2 but
    not sure he understands the proposals real well
    ... any comments?

    <tlr> zkim, mute me

    RB: I think E, F and G can be addressed with the same approach

    <darobin> RB: basically if we define a URI mapping for the widget:
    URI scheme such that it resolves to representations (files) in the
    widget archive, and that makes locales invisible  which addresses
    all issues at once

    TR: whatever we do to map URIs to files need consistency b/w sig and
    l10n piece
    ... I'm not opppsed to this but must think about impact of signature
    model
    ... need to think about the addressing issue when considering these
    proposal

    RB: shoudn't the sig be at the file layer and nothing to do at the
    resolution layer

    TR: that may be the right soln; but must make sure it really works
    ... must be very careful; not sure we've done all the work
    ... if the two can be separated that would be good

    <tlr> the main point is that signatures expect URI references there.

    MC: I don't yet understand either TR's proposal nor RB's proposal

    <tlr> Relative URI references in there might lead to funny errors.

    <tlr> so, careful

    <tlr> that's one of the reasons for a widget URI scheme.

    <darobin> I think that for all intents and

    <darobin> purposes, the user agent should behave as if content from
    the most

    <darobin> specific locale had been copied into less specific locales
    recursively

    <darobin> until they are copied to the root, and the locales
    directory is

    <darobin> discarded.

    MC: yes, that is one of the proposals I made

    RB: it is sorta' like one of your proposals but not exactly

    MC: ok, so maybe they are the same

    <darobin> also:

    <darobin> The justification behind this approach is that: a) locales
    should be

    <darobin> transparent, and b) there is no requirement to have the
    widget URI map

    <darobin> *directly* unto the widget's structure. In fact, it is
    probably best

    <darobin> if it's not possible inside locales/en/index.html to go
    "<a href='../

    <darobin> fr/index.html'>Frog version</a>".

    RB: the idea is to change the base URI

    MC: the reason we proposed rewriting the URI is to get
    predictability
    ... but effectively, it should work as Robin is proposing
    ... want developer to easily know where files come from
    ... I'm OK with this proposal
    ... we do have some concerns it will cause confusion
    ... but if there is consensus to go that route I am willing to
    update my proposal

    RB: it effect F and G as well

    MC: yes agree

    <tlr> I think I'm resigned to this.

    RB: you wouldn't have missing localized content in my model

    MC: yes, true; and we wouldn't need XML Base

    RB: yes, correct

    AB: what about the G proposal MC if you went with RB's proposal?

    MC: if we go with RB's propsal, we eliminate E, F and G and they
    become a single proposal

    AB: that certainly sounds like a win to me
    ... any other comments?

    <tlr> +1 to robin

    <tlr> that's the context in which it needs to be discussed

    <marcos> proposal 1: pretend to copy everything to the root of the
    widget. 2: Pretend everything has been copied in the locale folder.

    [ Pause while MC' enter's proposal into IRC ]

    RB: this part of the proposal could go in the widget URI spec

    <darobin> RB: I think that this could go into the wURI document

    MC: I prefer Option #1

    RB: I prefer that option too

    AB: any other comments?

    RB: proposals A thru D would go in P+C spec
    ... and the E+F+G would go in the URI spec

    MC: I agree with RB's plan above

    AB: any comments about this plan?
    ... I support it
    ... what about time frames RB and MC?

    RB: I can do it by May 5

    MC: I can it by May 7

    AB: propose E+F+G proposal from Robin be merged into a single
    proposal and added to the Widget URI spec
    ... any objections?

    RESOLUTION: E+F+G proposal from Robin will be merged into the Widget
    URI spec

    AB: thanks to Marcos for working on this doc!

Security related issues with "core" Widgets specs (from Thomas):

    AB: on 28 April Thomas identified
    ([26]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0
    370.html) two high priority security concerns regarding what I
    called "core" widget specs: 1) How are relative URI references
    absolutized? and 2) How do widgets interact with the HTML5 security
    policy? Thomas, would you please start with a short introduction to
    the first issue?

      [26] http://lists.w3.org/Archives/Public/public-webapps/ 
2009AprJun/0370.html)

    <tlr> This translates into "the widget URI spec"

    TR: the most important thing is what goes in the Widget URI spec
    ... the second question is the more critical question
    ... e.g. HTML5 frame communication
    ... that will be used by widgets
    ... need to get agreement on the origin property
    ... the current approach is trying to solve both of these problems
    at once
    ... we need to get the URI spec right!
    ... we can defer this discussion to the URI spec agenda topic
    ... must get origin and addressing right

    <tlr> ACTION: thomas to review <access> element by Tuesday [recorded
    in [27]http://www.w3.org/2009/04/30-wam-minutes.html#action03]

    RB: would you please review the <access> element by May 4 / 5?

A&E spec: Per-instance Storage discussion

    AB: last week there was a discussion about the Storage interface
    ([28]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0
    301.html) and whether or not
    ... the spec should say something about widget instances and Storage
    interface

      [28] http://lists.w3.org/Archives/Public/public-webapps/ 
2009AprJun/0301.html)

    Arve: Storage interface should be instantiated per widget
    ... that has always been clear to me
    ... an issue is the origin

    RB: we have been talking about this in the context of the URI scheme

    MC: when we hit URIs we hit origin; they can't be separated
    ... there is a dependency of Storage and origin
    ... it is based on identity
    ... must make sure the storage area is not shared
    ... we want widgets to have their own storage
    ... instance must not share storage, cookies, etc.

    RB: you mean instances of the same widget?

    MC: yes

    RB: if the origin is constant after it is installed, if it is run,
    stopped, run again should have same origin

    TR: must separate addressing and origin

    RB: we have been having some related discussion with Anne

    TR: could have some shared storage
    ... I hear Arve state a requirement that can be easily solved
    ... but I think Guido has a req for shared storage

    Arve: I don't get the req for shared storage
    ... I can understand shared data
    ... but not shared Storage

    <darobin>
    [29]http://www.w3.org/mid/644AF4A6-9D1F-4D99-ACEB-E3A68398AA6E@berjo
    n.com

      [29] http://www.w3.org/mid/644AF4A6-9D1F-4D99-ACEB- 
E3A68398AA6E@berjon.com

    <scribe> ACTION: [recorded in
    [30]http://www.w3.org/2009/04/30-wam-minutes.html#action04]

    <scribe> ACTION: Guido submit shared storage requirement to
    public-webapps [recorded in
    [31]http://www.w3.org/2009/04/30-wam-minutes.html#action05]

    TR: I agree with Arve; the conversation I had with Guido was about a
    different requirement
    ... if everyone is OK with per-instance storage, that is OK with me
    ... just wanted to let you know a shared Storage req may come up

    Arve: we need a good definition of instance

    <trackbot> Sorry... I don't know anything about this channel

    <trackbot> If you want to associate this channel with an existing
    Tracker, please say 'trackbot, associate this channel with #channel'
    (where #channel is the name of default channel for the group)

    trackbot, this is WebApps

    <trackbot> Sorry, ArtB, I don't understand 'trackbot, this is
    WebApps'. Please refer to [32]http://www.w3.org/2005/06/tracker/irc
    for help

      [32] http://www.w3.org/2005/06/tracker/irc

    trackot, associate this channel with #webapps

    <tlr> tracbot, this is webapps

    trackbot, associate this channel with #webapps

    <trackbot> Associating this channel with #webapps...

A&E spec: Comments from Rainer:

    AB: on 24 April Rainer submitted some comments against the A&E spec
    ([33]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0
    335.html). There has been response. Marcos, Arve - what is your
    position on these comments?

      [33] http://lists.w3.org/Archives/Public/public-webapps/ 
2009AprJun/0335.html).

    Arve: these comments are just bug reports; all proposed changes are
    fine with me

    MC: I haven't looked at those comment yet

    AB: I'm trying to get a sense of whether any of these comments are
    considered substantial

    Arve: no, I don't think so

    BS: I sent the access element comments to the list so please close
    that action

A&E spec: What needs to be done before publishing a LCWD?

    AB: let's take this to the mail list. Arve, Marcos - would one of
    you please agree to an action to send a list of open issues and
    actions that must be addressed before we can publish a LCWD of the
    A&E spec? Would be best if you would include proposals on how to
    address the issues and action.

    MC: Ok

Widget URI Scheme

    AB: earlier today Robin requested some additions
    ([34]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0
    438.html) to the agenda. Robin, what do you want to discuss first?

      [34] http://lists.w3.org/Archives/Public/public-webapps/ 
2009AprJun/0438.html)

    <darobin> "who volunteers to handle the the URL path to Zip relative
    path mapping (and back)"

    RB: I'll paste in something MC noted
    ... we need to assign an Action so someone can take this
    ... MC, can you take it?

    MC: yes I can take it but we'll need to work on it together
    ... must make sure what we do is in accordance with IRI

    TR: please do not define a way to decode an IRI

    MC: we must define how to do the mapping though

    <darobin> "do we need UUIDs in widget URIs"

    <darobin> [35]http://dev.w3.org/html5/spec/#origin

      [35] http://dev.w3.org/html5/spec/#origin

    RB: I think we can do without them
    ... use HTML5 mechanism
    ... if we drop UUID we can use that

    <marcos> the uri scheme looks like widget://path

    RB: based on discussions with Anne and MC, I think we can do this

    TR: it is probably useful to say what the origin looks like e.g.
    large random num

    <darobin> HTML5 says "globally unique identifier"

    TR: if we need to have instance to instance comm
    ... we will need a widget specific uri scheme

    [ Scribe is not getting TR's comments .... ]

    <arve> me neither

    TR: two probs: how to identify something in the package

    <darobin> tlr's comments are largely at:
    [36]http://lists.w3.org/Archives/Public/public-pkg-uri-scheme/2009Ma
    r/0000.html

      [36] http://lists.w3.org/Archives/Public/public-pkg-uri-scheme/ 
2009Mar/0000.html

    TR: also need to ref things within the pack from outside the package

    RB: need to separate two things
    ... inter widget comm is dropped for v1

    RESOLUTION: inter widget communication is dropped for v1

    <marcos> +q

    <marcos> -q

    Arve: why do you want to use a widget to directly access another
    widget's package?
    ... do you want to access the resources in a widget ?

    TR: want to understand the relationship between html5 offline apps
    and widgets
    ... want same app code from a web app to work with a widget
    ... the addressing part is critical
    ... don't want an artifical boundary between web apps and widgets
    ... if we use a diff addressing scheme there will be problems

    MC: but some web apps have a sec model that just won't work with
    widgets

    TR: want to avoid the artificial boundary
    ... can we make the widget model and web app model converge-able? I
    think we can if we get the addressing right.

    <marcos> <content src="[37]http://gmail.com/#inbox" />

      [37] http://gmail.com/#inbox

    MC: we don't allow resources to address a web page e.g. via the
    <content> element
    ... we need to keep things relatively constrained for v1

    RB: I think there is transition path from the model we're thinking
    and the one TR wants
    ... think the bridge could be there and v2 can move to the new model

    TR: most v2's are mythical

    AB: what's the next step?
    ... do we want to get a FPWD in May?

    RB: yes

    TR: I am willing to work on the redirection layer
    ... if RB has a migration path in mind, I'd like to understand it
    more
    ... for sig and l10n we do indeed need something like the URI scheme

    AB: Meeting Ajourned

    <arve> I wasn't kidding when I said I was publishing the pics:
    [38]http://www.flickr.com/photos/arvebersvendsen/3488989846/

      [38] http://www.flickr.com/photos/arvebersvendsen/3488989846/

Summary of Action Items

    [NEW] ACTION: [recorded in
    [39]http://www.w3.org/2009/04/30-wam-minutes.html#action04]
    [NEW] ACTION: bryan submit an email to public-webapps re the
    <access> element [recorded in
    [40]http://www.w3.org/2009/04/30-wam-minutes.html#action01]
    [NEW] ACTION: Guido submit shared storage requirement to
    public-webapps [recorded in
    [41]http://www.w3.org/2009/04/30-wam-minutes.html#action05]
    [NEW] ACTION: Robin to edit access to take into account OMTP
    feedback and Bryan's [recorded in
    [42]http://www.w3.org/2009/04/30-wam-minutes.html#action02]
    [NEW] ACTION: thomas to review <access> element by Tuesday [recorded
    in [43]http://www.w3.org/2009/04/30-wam-minutes.html#action03]

    [End of minutes]
Received on Thursday, 30 April 2009 14:48:07 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:31 GMT