W3C

- DRAFT -

Widgets Voice Conference
02 Oct 2008

Agenda

See also: IRC log

Attendees

Present
Art, Marcos, Mark, David, Adam, Arve, Claudio, Benoit, Josh, MikeSmith
Regrets
Thomas, Nick
Chair
ArtB
Scribe
Art

Contents


 

 

<arve> sorry, will call in in 15 seconds

<timeless> s the meeting number

<scribe> Scribe: Art

<scribe> ScribeNick: ArtB

Date: 2 October 2008

Agenda tweaks

AB: any change requests?

[None]

Annoucements

AB: registration deadline for Mandelieu is now Oct 12
... Mandelieu agenda is still a WIP
... Security WS in December

MC: I intend to submit a Position Paper

AB: pub moratorium is Oct 13

Widgets Core API and Event spec

AB: what's the status Arve?

Arve: I just committed a new version to CVS
... http://dev.w3.org/2006/waf/widgets-api/
... we need to talk about using HTML5 APIs instead of get/set prefs
... does the refs section need to be complete?

MC: I think you can leave it open

<arve> http://dev.w3.org/2006/waf/widgets-api/Overview.src.html

AB: anything else blocking pub?
... may want to provide a bit more context for the red blocks

BS: I agree

Arve: yes, I can do that

BS: a list of issues would be helpful; gives the reader a sense of what's going to be done

Preferences API

AB: Marcos made a propsal on the list http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/ 0736.html

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

JS: I like the idea of dropping the APIs and using HTML5

<arve> +1

MC: the basic problem is we are defining an API that is already defined in HTML5
... this will cause probs for developers
... we don't want to have two different APIs
... I recommend we use HTML5
... It has already been implemented in some browsers

Arve: I quite agree with Marcos
... but we need to mention some stuff
... if we are going to do that
... For example, need to make it clear each widget instance has its own cache

MC: agree we may need to do some tweaks
... need to understand the overlaps of our reqs with HTML5

Arve: need to add some explicit requirements for the UA
... we may need to define a UA context
... that says something about caching, redirects, etc.
... Stuff that is beyond the scope of HTML5
... The interface is defined in HTML5 but not the implications in our context

JS: regarding reqs, need to also think about the need for storage to grow

<arve> We need to define: Widget instance caching context, widget instance security context, widget instance storage context

AB: where would this stuff be documented?

Arve: in the P&C spec

MC: I'm fine with that

AB: agree this contextual info would be good to document
... but who is going to create that documentation?
... does Opera have some documentation we could review?

Arve: another option is to go back to Opera's security input and move it forward

<arve> what we're saying currently is:

<arve> Separate widget instances share no information at all. Specifically:

MC: yes, maybe this information should not in P&C but rather in a separarte doc such as Widgets Sec Model

<arve> A cookie set by a widget instance, or by a URL loaded by a widget (eg through XmlHttpRequest) is visible only to that widget instance, never to any other instances or to documents loaded into the browser in any other way.

<arve> If a URL loaded by a widget requires HTTP authentication then authentication must be performed on behalf of that widget instance; the authentication is not shared with other widget instances or with URLs loaded into the browser in any other way.

<arve> A set of settings for a widget instance is shared with no other widget instances.

<arve> Other persistent storage mechanisms, such as those defined in HTML must not share data with other widget instances, or with the storage context in the web browser.

<arve> Cache files or cache indexes are not shared with the web browser, or with any other widget instance

BS: I think this type of info is good to have

AB: I tend to agree with Marcos this information should not be put in the P&C spec

BS: in the advertising context, cookies are a concern; don't want any breaches

AB: propose we drop our own storage APIs in the API spec and use HTML5's storage APIs
... any objections?

[None]

RESOLUTION: we will drop the storage APIs in the API and Events spec and use the HTML5 storage APIs

CV: advertising in Widgets may require more discussion on storage APIs

P&C feature element and access element

MC: currently we have <access> to state pref for network access, plugins, etc.
... that functionality is replicated by <feature>

<marcos> in <access> we had: <access network="true" etc....>, Dom proposed we change it to <widget access="network plugins etc..">, then Arve wanted to replace all that with <feature id="http://www.w3.org/widgets/network">

MC: I discussed this with Arve
... Dominque recommended access just be an attribute on <widget>
... we can also use URIs on <feature>
... this give much more fine-grained control
... Yahoo provides more control but not using URIs

Arve: Opera provides fine control too
... if we have URIs we can extend easily

AB: any other feedback?

MC: also could be used to define device capabilities
... e.g. using fragment ids or query strings

CV: we're not sure network access and feature are at the same level
... we think access should be kept
... something like network access is important, especially for mobile operators

Arve: I think our proposal can be used to provide the exact same info that can be specified in <access network=@@@">

AB: since this is the first time we've seen this proposal, I don't think we should make a decision today
... Would like MC and/or Arve to submit their proposal to the list for feedback

Arve: agree; this is a strawman proposal now; we need feedback

CV: I agree we need to have some discussion on this
... need to make sure it covers all of our use cases

MC: I agree with Claudio
... think <access> can be useful as well as <feature>

AB: what are your thoughts on this Marcos?

MC: I can create a proposal for a model to address this discussion and the requirements

P&C <span> element

AB: the I18N WG submitted some comments on the <span> element
... what is the status Marcos?

MC: we have to do something

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

MC: options are to add <span> or the ITS spec
... My concern is about mandating support for ITS

AB: I tend to share that concern about ITS support

<marcos> MC: for example <description> bla bla <its:span> blo blo</its:span> </description>

AB: do we just reuse its:span?

MC: yes, but supporting ITS adds a lot of complexity

AB: should we punt on this for v1?

MC: I can do some investigation on this
... I think it's OK to drop it for v1 and plan to add it to v2
... we already have a number of I18N features

AB: is anything hearing mandatory support for ITS for v1?

JS: I'm worried about the implementation burden about this
... if we support Unicode we should be OK for v1
... Also could make authoring more difficult

<marcos> this is what Felix said: "To keep simplicity for Widgets 1.0, you could say in your conformance

<marcos> description that a Widgets processor has various options to deal with

<marcos> the <its:span> element (or more in general: the ITS namespace) and its

<marcos> attributes: ignore them or process them

<marcos> "

JS: It would be real helpful if we had a validator for a manifest

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

MC: I can codify Felix' recommendation

AB: I can live with that for v1
... I propose Marcos codify Felix' recommendation to address the span issue
... any objections?

[None]

RESOLUTION: Marcos will codify Felix's recommendation to address the span issue (http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0626.html)

Dig Sig spec

AB: status from Mark or Marcos?

MC: I haven't been working on it

MP: neither have I
... I have done some stuff on update and sent it to Marcos

JS: should we invite XML Sig WG?

AB: I've already done that - Tues Oct 21 11:00-12:00

<scribe> ACTION: Barstow ping the XML Sig WG re the questions we sent to them last week [recorded in http://www.w3.org/2008/10/02-wam-minutes.html#action01]

<trackbot> Created ACTION-253 - Ping the XML Sig WG re the questions we sent to them last week [on Arthur Barstow - due 2008-10-09].

MC: David, are you going to send us some info OMTP re the DigSig spec?

DR: I'll follow-up with Nick

AB: Meeting Closed

Summary of Action Items

[NEW] ACTION: Barstow ping the XML Sig WG re the questions we sent to them last week [recorded in http://www.w3.org/2008/10/02-wam-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/10/02 12:05:41 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: Art
Found ScribeNick: ArtB
Present: Art Marcos Mark David Adam Arve Claudio Benoit Josh MikeSmith
Regrets: Thomas Nick
Agenda: http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0001.html
Found Date: 02 Oct 2008
Guessing minutes URL: http://www.w3.org/2008/10/02-wam-minutes.html
People with action items: barstow

[End of scribe.perl diagnostic output]