W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2008

[widgets] Minutes from 2 October 2008 Voice Conference

From: Arthur Barstow <art.barstow@nokia.com>
Date: Thu, 2 Oct 2008 08:18:49 -0400
Message-Id: <5A3CDBF2-CF33-4B25-8B55-3CB6CE18E60D@nokia.com>
To: public-webapps <public-webapps@w3.org>

The minutes from the October 2 Widgets f2f meeting are available at  
the following and copied below:


WG Members - if you have any comments, corrections, etc., please send  
them to the public-webapps mail list before October 9 (next Widgets  
voice conference); otherwise these minutes will be considered approved.

-Regards, Art Barstow


       [1] http://www.w3.org/

                                - DRAFT -

                        Widgets Voice Conference
                               02 Oct 2008


       [2] http://lists.w3.org/Archives/Public/public-webapps/ 

    See also: [3]IRC log

       [3] http://www.w3.org/2008/10/02-wam-irc


           Art, Marcos, Mark, David, Adam, Arve, Claudio, Benoit, Josh,

           Thomas, Nick




      * [4]Topics
          1. [5]Agenda tweaks
          2. [6]Annoucements
          3. [7]Widgets Core API and Event spec
          4. [8]Preferences API
          5. [9]P&C feature element and access element
          6. [10]P&C <span> element
          7. [11]Dig Sig spec
      * [12]Summary of Action Items

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



    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
    ... [13]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?

      [13] http://dev.w3.org/2006/waf/widgets-api/

    MC: I think you can leave it open

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

      [14] 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

      [15] http://lists.w3.org/Archives/Public/public-webapps/ 


      [16] http://lists.w3.org/Archives/Public/public-webapps/ 

    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

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

    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?


    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

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

      [17] 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


      [18] http://lists.w3.org/Archives/Public/public-webapps/ 

    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


      [19] http://lists.w3.org/Archives/Public/public-webapps/ 

    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?


    RESOLUTION: Marcos will codify Felix's recommendation to address the
    span issue

      [20] http://lists.w3.org/Archives/Public/public-webapps/ 

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

    <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

    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

    [End of minutes]
Received on Thursday, 2 October 2008 12:20:06 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:12 UTC