- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Thu, 29 May 2008 08:42:24 -0400
- To: public-appformats@w3.org
The minutes from the WAF WG's May 22 Widgets voice conference are
available at the following and copied below:
<http://www.w3.org/2008/05/29-waf-minutes.html>
WG Members - if you have any comments, corrections, etc., please send
them to the public-appformats mail list before June 5; otherwise the
minutes will be considered approved.
-Regards, Art Barstow
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Widgets Voice Conference
29 May 2008
[2]Agenda
[2] http://lists.w3.org/Archives/Member/member-appformats/
2008May/0011.html
See also: [3]IRC log
[3] http://www.w3.org/2008/05/29-waf-irc
Attendees
Present
Art, Claudio, Marcos, Arve, Mike
Regrets
Ben, Benoit
Chair
Art
Scribe
Art
Contents
* [4]Topics
1. [5]Review Agenda
2. [6]Announcements
3. [7]Auto-updates
4. [8]Widget Resource on the Web
5. [9]XML File
6. [10]Local Storage model (sub-proposal #3)
7. [11]API Call model (sub-proposal #4)
8. [12]WebApps WG Charter Update
9. [13]Next F2F Meeting
* [14]Summary of Action Items
_________________________________________________________
Date: 29 May 2008
<scribe> Scribe: Art
<scribe> ScribeNick: ArtB
Regrests: Ben, Benoit
Review Agenda
AB: any change requested?
[None]
Announcements
AB: next week's meeting June 5 - start time will be ONE HOUR
EARLIER!
Auto-updates
AB: proposal from Marcos
[15]http://lists.w3.org/Archives/Public/public-appformats/2008May/01
24.html
... is this your proposal or did you work with Arve?
[15] http://lists.w3.org/Archives/Public/public-appformats/
2008May/0124.html
MC: this started as my input but reflects comments from Arve, Mark
Baker and JonF
... this proposal includes several mechanisms
AB: orthoganal or complementary mechanisms?
MC: some are complementary and some are orthoganal
... there are four mechanism described in varying levels of detail
CV: agree some mechanisms are complementary but they seem to address
different use cases
... e.g. the 2nd mechanism gives some additional flexibility
... it could be viewed as an extension to the 1st proposal
ABe: the 2nd mechanism (XML file) can be done via a push to the UA
MC: using the hash is kinda' of a cheap dig sig scheme thus another
good thing about the XML format
AB: of these mechanisms, which is most commonly implemented today?
MC: #3 (local storage) is the most common i.e. just download a new
widget
... pretty much just leaves the details to the UA
... and hence doesn't require much standardization
ABe: these proposals are still a bit short on details
... think we need to explore the alternatives some more
MC: agree; I've started to expand the examples
... I will also include the various usage scenarios
AB: that would be excellent; we can then analyze the various
strengths and weakness of the different models
Widget Resource on the Web
<marcos> <update url="http:/a.com/myWidget.wgt"
etag="36f4d2e876c5c51:b74"/>
MC: this model requires author to include an update element with a
URI attribute
... the etag attr would be optional
... if etag is present can compare it with what is installed; if
different, assume a new widget exists
AB: we discussed that mechanism last year, right?
MC: yes, Mark Baker suggested the etag
... if etag is missing, the UA asks the user if they want to update
the widget
... this model uses HTTP caching mechanism
ABe: not sure what happens if the widget was obtained via some
non-http protocol e.g. Bluetooth
... think there is a trust issue with this model e.g. where did the
widget really come from
MC: right, a Widget could be copied from one site and installed
somewhere else
ABe: I'm concerned about tampering of un-signed widgets
... the update URI could have been altered by some means
... or the etag could be tampered
MC: yes, but I don't think we want to prescribe encryption
ABe: but the update document could be signed
MC: can also require httpS
... in the web today we see this issue being addressed by asking the
user if they really want to install something (e.g. FF installed
from a non-Mozilla site)
ABe: the main thing we must do is to clearly identify the security
considerations
XML File
ABe: an advantage of this model is the update format can be signed
... I think we need to flesh-out both of these models
MC: I think we should document both models
AB: would the server need to do anything special in this model?
MC: no it would not
... the update format could be done by hand given it is quite simple
AB: is this model being used today?
MC: yes it is being used by numerous systems (iTunes, Debian, ...)
... this is certainly more common than model #1
AB: what is the user interaction model for the XML format?
MC: one mechanism is the UA just tells the user a new version is
available
... another interaction model is a user explicitly checks a "check
for updates" sheet
ABe: I don't think we want to normatively specify the user
interaction model
... especially since the update could be done auto-magically
[withouth any user interaction at all]
MC: agree
AB: agree too
CV: the spec should enable different user interaction models
... want to leave both user interaction models open
MC: we will not recommend any user interaction model
CV: data exchange from device to server is important for operators
... the update process could be used to do advertising
MC: yes but such a widget would become un-popular
Local Storage model (sub-proposal #3)
MC: the UA compares the current widget id with the new widget
AB: will you Marcos submit details for this model too?
MC: yes there are some additional details to flesh out
API Call model (sub-proposal #4)
MC: author provides an update element in the config doc
... at runtime the script in the engine calls the update() method
... this causes the UA to ask the server for a new Widget
... basically, this would trigger model #1 or model #2
AB: will this one also be further explored?
MC: yes; in particular will need to add it to the API spec
ABe: yes, this will need to be detailed in the API spec
WebApps WG Charter Update
MS: the comment period has ended
... Doug has responded to all comments
... He has updated the charter to reflect the comments
... The deliverables list has been updated
... Most of the AC commentors are OK with the Team's responses
... we expected comments about too many deliverables but we didn't
get such feedback
... the only exception is Geo-location
... we expect to do the Geo-location API in a separate WG but that's
not yet a done deal because we first have to get AC review
... Access Control will remain in the WebApps WG
AB: thanks Mike
... our Charter ends May 31
MS: yes, we will need another short extension
AB: thanks to Mike and Doug for all of the time and effort they've
put into getting this done!
Next F2F Meeting
<MikeSmith> for the record, Doug did almost all of the work on the
charter and disposition comments (not me)
AB: the majority of preferences expressed in Dublin were to have the
next f2f in early September
... I'm happy to say Claudio can accomdate that
... next f2f meeting will be Sept 9-11 in Turin Italy
<scribe> ACTION: barstow announce Sept 9-11 to the WG [recorded in
[16]http://www.w3.org/2008/05/29-waf-minutes.html#action01]
<trackbot-ng> Created ACTION-179 - Announce Sept 9-11 to the WG [on
Arthur Barstow - due 2008-06-05].
<scribe> ACTION: barstow review TPAC meeting schedule and forward to
the WG [recorded in
[17]http://www.w3.org/2008/05/29-waf-minutes.html#action02]
<trackbot-ng> Created ACTION-180 - Review TPAC meeting schedule and
forward to the WG [on Arthur Barstow - due 2008-06-05].
AB: Meeting Adjourned
Summary of Action Items
[NEW] ACTION: barstow announce Sept 9-11 to the WG [recorded in
[18]http://www.w3.org/2008/05/29-waf-minutes.html#action01]
[NEW] ACTION: barstow review TPAC meeting schedule and forward to
the WG [recorded in
[19]http://www.w3.org/2008/05/29-waf-minutes.html#action02]
[End of minutes]
Received on Thursday, 29 May 2008 12:43:57 UTC