Widgets F2F Meeting -- 26 Aug 2008

Date: 26 August 2008

<scribe> Scribe: Art

<scribe> ScribeNick: ArtB

Introduction

<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?

[None]

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. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0450.html
... 2. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0451.html
... one issue is about proxies and we already identified that as an issue (#17)

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

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

[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 specs

<scribe> ACTION: Barstow close Issue #17 [recorded in http://www.w3.org/2008/08/26-wam-minutes.html#action01]

<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 discuss?

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

[none]

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

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 http://www.w3.org/2008/08/26-wam-minutes.html#action02]

<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

AB: http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets-reqs-20080625
... unfortunately this is a Member-only link
... I don't like this

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?

[None]

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 http://www.w3.org/2008/webapps/track/

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

<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 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 support?

<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 names"

<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 each

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

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

<barstow> MC: the I18N WG recommended this change

<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: <http://www.w3.org/mid/b21a10670808122128u4a8fac1erebd1f5d7cf90831f@mail.gmail.com>

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

<barstow> AB: issue is: 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 path

<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: 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 wrong.

<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> 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: http://dev.w3.org/2006/waf/widgets-reqs/#r6.-addressing Addressing Scheme and then continue discussion]

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

<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

<claudio> http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0328.html

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

<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 confs

<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 http://www.w3.org/2008/08/26-wam-minutes.html#action03]

<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> 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 reference

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

<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 UTF-8

<scribe> Scribe: Art

<scribe> ScribeNick: ArtB

P&C Issues

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

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

AB: issue #34 - 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 dies

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

MC: we could say something in the P&C spec but probably nothing normative
... 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?

[None]

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 http://www.w3.org/2008/08/26-wam-minutes.html#action04]

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

Issue #46 - Need to define a for i18n purposes in configuration document

AB: issue is 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 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

MC: probably just direction

BS: why do we need if localized text is placed in localized folders

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

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 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: 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> elements

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?

[None]

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 http://www.w3.org/2008/08/26-wam-minutes.html#action05]

<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: 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 implement
... 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 supported?

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?

[None]

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

<scribe> ACTION: Barstow close Issue #21 with the resolution above [recorded in http://www.w3.org/2008/08/26-wam-minutes.html#action06]

<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 info

<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

- DRAFT -

Widgets F2F Meeting
26 Aug 2008

Attendees

Contents

Introduction

Agenda Review

Last Call of Requirements Doc

Disposition of Comments document for the Requirement Last Call

Configuration and Packing Spec

ZIP Archive

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

URI Scheme and Query parameter

URI Scheme and Encoding

P&C Issues

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

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

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

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

Webwag presentation

Summary of Action Items

Scribe.perl diagnostic output

- DRAFT -

Widgets F2F Meeting 26 Aug 2008

Attendees

Contents

Introduction

Agenda Review

Last Call of Requirements Doc

Disposition of Comments document for the Requirement Last Call

Configuration and Packing Spec

ZIP Archive

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

URI Scheme and Query parameter

URI Scheme and Encoding

P&C Issues

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

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

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

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

Webwag presentation

Summary of Action Items

Scribe.perl diagnostic output

Widgets F2F Meeting
26 Aug 2008