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-e3a68398a...@berjo
n.com
[29] http://www.w3.org/mid/644AF4A6-9D1F-4D99-ACEB-
e3a68398a...@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]
