Widgets Voice Conference

30 Apr 2009


See also: IRC log


Art, Mike, Robin, Marcin, AndyB, Frederick, Marcos, Arve, Bryan, Thomas
AndySledd, Mark, David




<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 (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0405.html). Since then Robin requested some additions (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0438.html) and we will add those agenda items. Any other change requests?

[ None ]

Topics: Announcements

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

[ None ]

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

AB: on April 23 David submitted some comments regarding the <access> element (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0291.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

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 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 http://www.w3.org/2009/04/30-wam-minutes.html#action02]

AB: last week Marcos provided a short introduction to L10N model he proposed (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 (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0409.html), AndyS (h

So far, preferences for the proposals have been submitted by at least Robin (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0409.html), AndyS (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0436.html), Francois (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0350.html) and myself (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 (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0370.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?

<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 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 (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0301.html) and whether or not
... the spec should say something about widget instances and Storage interface

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> http://www.w3.org/mid/644AF4A6-9D1F-4D99-ACEB-E3A68398AA6E@berjon.com

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

<scribe> ACTION: Guido submit shared storage requirement to public-webapps [recorded in 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 http://www.w3.org/2005/06/tracker/irc for help

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 (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0335.html). There has been response. Marcos, Arve - what is your position on these comments?

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 (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0438.html) to the agenda. Robin, what do you want to discuss first?

<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> 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: 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="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: http://www.flickr.com/photos/arvebersvendsen/3488989846/

Summary of Action Items

[NEW] ACTION: [recorded in 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 http://www.w3.org/2009/04/30-wam-minutes.html#action01]
[NEW] ACTION: Guido submit shared storage requirement to public-webapps [recorded in 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 http://www.w3.org/2009/04/30-wam-minutes.html#action02]
[NEW] ACTION: thomas to review <access> element by Tuesday [recorded in http://www.w3.org/2009/04/30-wam-minutes.html#action03]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009/04/30 14:41:27 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found ScribeNick: ArtB
Found Scribe: Art
Present: Art Mike Robin Marcin AndyB Frederick Marcos Arve Bryan Thomas
Regrets: AndySledd Mark David
Agenda: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0405.html
Found Date: 30 Apr 2009
Guessing minutes URL: http://www.w3.org/2009/04/30-wam-minutes.html

WARNING: No person found for ACTION item:  [recorded in http://www.w3.org/2009/04/30-wam-minutes.html#action04]

People with action items: an bryan email guido requirement robin shared storage submit thomas

[End of scribe.perl diagnostic output]