W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

[widgets] Minutes from 26 February 2009 Widgets F2F Meeting

From: Arthur Barstow <art.barstow@nokia.com>
Date: Thu, 26 Feb 2009 11:21:19 -0500
Message-Id: <AB666BE1-AD8F-4907-8FD7-678457FA3301@nokia.com>
To: public-webapps <public-webapps@w3.org>
The minutes from the February 26 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 5 March 2009 (the next  
Widgets voice conference); otherwise these minutes will be considered  

-Regards, Art Barstow


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

                                - DRAFT -

                           Widgets F2F Meeting

26 Feb 2009


       [2] http://www.w3.org/2008/webapps/wiki/WidgetsParisAgenda

    See also: [3]IRC log

       [3] http://www.w3.org/2009/02/26-wam-irc


           Art, Claudio, Ivan, Mohammed, Rainer, David, Arve, Marcos,
           Benoit, Mike, Doug, Josh, Thomas




      * [4]Topics
          1. [5]Agenda Review
          2. [6]Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs
          3. [7]A&E Red Block Issues
          4. [8]BONDI and Widget Specs
          5. [9]Widget URI Scheme
          6. [10]Schedules
          7. [11]Guest Presentation
      * [12]Summary of Action Items

    <ArtB> ScribeNick: ArtB

    <scribe> Scribe: Art

    Meeting Widgets F2F Meeting

    Date: 26 Feb 2009

    zaki, who is here?

Agenda Review

    AB: last day
    ... and 13:30 Scott Wilson some other Widget implementors will join
    us for for an hour or two
    ... Topics remaining:
    ... 1. A&E spec
    ... 2. AOB
    ... from my perspective, we are done with P&C for this meeting
    ... is that consistent with everyone else?

    [ No additional P&C topics suggested ]

    AB: I presume no more DigSig discussions, right?

    MC: no, done with DigSig

    [ Short discussion about when people need to leave today to catch
    their planes ... ]

    AB: we will plan to complete WG discussions by 13:30

Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs Storage

    AB: head of the thread:
    ... where do we stand on this Marcos?

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

    Arve: I do not support removing preferences interface

    MC: want to keep preferences API
    ... but say storage is guaranteed
    ... I don't want to explicitly say HTML5 storage is mandatory
    ... Also don't want to replicate HTML5's storage API
    ... It still may change
    ... We also now have a <preference> element that can be used

    CV: please elaborate on the concern about read-only prefs

    MC: we want read-only prefs

    CV: what is the rationale for read-only?

    MC: they can be read-only or modifiable
    ... that is, it will be possible to explicitly identify a specific
    pref to be read-only (non-mutable)
    ... We expect some prefs e.g. a key to not be modifiable

    Ivan: we have getPrefs + setPrefs but you also want the prefs array
    ... is that too much flexibility?

    MC: no, I think this flexibility is good
    ... want an object that can be iterated over
    ... but can also explicitly set and get via methods

    Arve: but if it looks like an array and talks like an array ...

    MC: it's like a hash map

    Arve: don't understand why I can't set/get the collection
    ... e.g. to bulk add keys

    MC: let me try to clarify my proposal

    AB: preferences definition:

      [14] http://dev.w3.org/2006/waf/widgets-api/#the-preferences- 

    [ Marcos sketches the API for preferences; this will be pasted into
    IRC ... ]

    <Marcos> interface preferences{

    <Marcos> void setPreference();

    <Marcos> string getPreference ();

    <Marcos> array keys;

    <Marcos> void clear();

    <Marcos> void size;

    <Marcos> }

    Ivan: how is delete done?

    MC: set it to null

    <timeless> void size doesn't make sense

    Ivan: this could create a collision problem

    <arve> in contrast, HTML5 storage:

    <arve> interface Storage {

    <arve> readonly attribute unsigned long length;

    <arve> [IndexGetter] DOMString key(in unsigned long index);

    <arve> [NameGetter] DOMString getItem(in DOMString key);

    <arve> [NameSetter] void setItem(in DOMString key, in DOMString

    <arve> [NameDeleter] void removeItem(in DOMString key);

    <arve> void clear();

    <arve> };

    <arve> if (!localStorage.pageLoadCount)

    <arve> localStorage.pageLoadCount = 0;

    <arve> localStorage.pageLoadCount =
    parseInt(localStorage.pageLoadCount, 10) + 1;

    <arve> document.getElementById('count').textContent =

    <arve> preferences["catnip"] = "delicious for cats";

    MC: oh, I see ...

    AB: so what does this mean MC?

    MC: well, my strawman isn't right; I'll need to look at what Arve

    Arve: this is from the Storage interface

    [ Marcos creates proposal #2; he will paste this into IRC
    momentarily ... ]

    AB: so are we then building a dependency on HTML5?

    <Marcos> interface Preferences {

    <Marcos> readonly attribute unsigned long length;

    <Marcos> [IndexGetter] DOMString key(in unsigned long index);

    <Marcos> [NameGetter] DOMString getItem(in DOMString key);

    <Marcos> [NameSetter] void setItem(in DOMString key, in DOMString

    <Marcos> [NameDeleter] void removeItem(in DOMString key);

    <arve> preferences["cats"] = "dogs"

    <Marcos> void clear();

    <Marcos> };

    MC: no, not really because we are changing the name of the interface

    AB: any comments on this proposal?

    Arve: this is a starting point
    ... prolly don't want to continue to design this API during this
    ... what about read-only
    ... needs the stuff from the manifest

    MC: could have a revert method

    Arve: or restore

    MC: we aren't putting a depedency on HTML5
    ... but we are leaching its Storage interface, renaming it and
    adding some new methods
    ... We may also want to change the name of the getters and setters

    <timeless> getItem and setItem are generally magically in dom impls

    <timeless> so changing their names is painful

    Arve: not sure we want to change get/set names

    <timeless> so, idl won't let us take an existing interface and say
    'for this method, additional exceptions will happen: ...'?

    Arve: I will create a new proposal for this

    <timeless> if you were only going to change the name of the bound
    thing, i'd have hoped you didn't need to give it a new name, and
    simply say: interface Widget { ... HTML5::Storage preferences; ... }

    Arve: by that I mean I will update the spec to match what we agree

    <arve> timeless: I don't want that dependency

    <Marcos> timeless: same here

    <Marcos> We are assuming and SVG only widget engine

    <Marcos> for instance

    <arve> and the objects stored within are not, like html5,
    domstrings, but Preference objects

    AB: any other feedback for MC or Arve on this?

    Ivan: this looks like the right direction; I'm not so concerned
    about the specifics

    <scribe> ACTION: Marcos work with Arve to update the preferences API
    to reflect discussions on 26-Feb-2009 [recorded in

    <trackbot> Created ACTION-313 - Work with Arve to update the
    preferences API to reflect discussions on 26-Feb-2009 [on Marcos
    Caceres - due 2009-03-05].

    Ivan: David, what is BONDI defining for storage?

    DR: I'm not sure

    RH: using key/value storage and File I/O

    AB: agenda for A&E

      [16] http://www.w3.org/2008/webapps/wiki/ 

    <MikeSmith> yes

    <MikeSmith> still here, but muted

    <Marcos> MikeSmith: is annevk staying with you?

    <MikeSmith> Marcos, yeah

A&E Red Block Issues

    AB: do we still have a HTML5 depedency issue?

    MC: no

BONDI and Widget Specs

    <scribe> ScribeNick: claudio

    <MikeSmith> I'm here

    DR: has sent information to the list about BONDI candidate release
    ... OMTP intention is bringing APIs into W3C
    ... just want to understand whether to target existing W3C groups or
    new ones

    AB: good overview, referencing W3C specs actually means targeting
    working drafts

    <MikeSmith> tlr, can you call in for a bit please?

    <tlr> errm, I don't even know what's on the agenda right now?

    AB: BONDI may begin to implements w3c specs which are in working
    draft status

    Doug: It is not really a novelty
    ... it is more about what constraints they are going to bring to

    DR: we say we reference W3C there's any intention to diverge or fork

    MC: risk of forking is very high

    DR: We'll make all the efforts to avoid it either in referencing or
    when we'll be extending those

    <timeless> AS-0050 Support SHALL be provided for remotely-initiated
    Widget Resource de-installation

    Arve: providing initial inputs and anticipating results may not work

    DR: we want to of course to influence but don't whant to create
    inconsistecies or break any process

    AB: can you adjust the process to address this concerns?

    <timeless> AS-0160 The system SHALL by default inhibit automated
    update of widget resources over PLMN when in roaming mode

    DR: we want to prevent fragmentations not create new ones anyhow

    AB: reducing fragmentation is good but the current situation would
    lead to increase rather then reduce it

    TR: so you would track changes created in BONDI to W3C?

    DR: DR we are referencing p&c not cut and pasting pieces of that

    Doug: what if a working draft changes critical apsects of already
    implemented previous working draft?

    <Marcos> +q to about test suite

    DR: we don't want to break any spec with our extensions
    ... it is more a natural evolution addressing market needs

    Doug: Will OMTP take responsibility of maintain consistency?

    DR: yes

    Doug: We don't want to create frustration in the market

    MC: the risk is that vendors won't claim conformance
    ... different implementation and frustrations lead to fragmentation

    <ivandm> I did! :)

    MC: developers would find incompatible interfaces and so on
    ... Opera has business requirements too here
    ... you might consider the way around come to W3C and help us speed
    up things from inside

    DR: many of us are members of OMTP and have already deployed widgets
    ... isn't it fragmentation?

    <tlr> art, can I speak, pleasE?

    Arve: OMTP is committing resource in a spec to which non OMTP
    members don't have any visibility

    TR: the mainstream discussion should be inside this WG
    ... we should start thinking a serious strategies against

    <Marcos> tlr, the packaging spec defines all conformance checker

    TR: put additional effort in test suites, validators

    DR: it seems to me that there is too much suspicion in the air
    ... we do leave things open to public feedback
    ... we are already putting resources here and we'd put more on
    validators if needed

    <Marcos> -q

    Doug: validator should help transforming docs to more conformant
    ... if there is a clear strategy I'm not concerned implementations
    are always valuable

    AB: spec extension have to be supported although inconsistent to
    original specs

    <Marcos> +q to the ultimate solution

    Claudio: what about w3c and OASIS liason it seems to work well

    <ArtB> CV: can we leverage any experiences from W3C + OASIS liaison
    that could be applicable in this case?

    TR: there's an overhead in admin in this kind of liason
    ... here is different, we don't want work that modify the widget
    spec defined in this group

    AB: want to mention that within two weeks BONDI is going to
    implement specs
    ... they will take W3C spec as they are

    <tlr> that is extremely useful information

    TR: patent policy doesn't cover things which are not reccomendation
    ... patent policy and process are not separable
    ... if it is very valuable for everybody you can make it but

    Doug: this might lead to to patent related issues we should consider

    TR: going out of the process is dangerous

    <drogersuk> Members make an RF commitment on joining the group

    TR: it might not help the ecosystem at all at the end

    DR: OMTP will continue to reference spec as they evolve to final
    release to reduce fragmentation

    <tlr> drogers: OMTP will reference specifications as they evolve,
    all the way to REC

    DR: will continue to commit resources here to ensure it

    <tlr> drogersuk, if the discussions that are within the scope of
    this group are happening here, then there was a misperception

    DR: we'll keep our independent status

    MC: two or three OMTP editors should come and help going on with the

    TR: when do we get editor names?

    <ArtB> ACTION: Rogers create a proposal for OMTP members to supply
    Editor(s) for the Widgets specs [recorded in

    <trackbot> Created ACTION-314 - Create a proposal for OMTP members
    to supply Editor(s) for the Widgets specs [on David Rogers - due

    DR: I will strongly reccommend it to OMTP and come back to you with
    an answer soon
    ... to clarify that we don't want to diverge

    MC: Mark Priestley was great but we need somebody else

    DR: OMTP will continue providing resources to this meeting and do
    its best for prevent forking
    ... forking is going off and never come back

    AB: but you create a divergence point anyhow

    <annevk> (Opera's widgets implementation uses a different media

    <annevk> (so it's vastly different)

    Doug: looking forward to hear about evolution strategies and
    resources form OMTP

    <ArtB> ScribeNick: ArtB

Widget URI Scheme

    AB: what did BONDI do about this issue?

    DR: we are going to take WebApps' lead

    AB: what will you tell your implementors next week?

    MC: I couldn't find anything in the BONDI specs
    ... file: has holes

    Arve: think we need to take a few steps back
    ... need a URI resolution mechanism

    DR: the TAG didn't respond to MC's last email right?

    MC: tag URI scheme has some pros and cons
    ... see
    ... doesn't meet all of our reqs
    ... to create a new URI scheme is objectionable by the TAG

      [18] http://www.w3.org/2008/webapps/wiki/ 

    Arve: for: every scheme we have investigated has had at least one
    ... i.e. no existing scheme meets all of our reqs

    MC: I've asked the package API mail list "what do we need to do to
    make the tag: URI scheme compatible with IRIs?"

    Arve: what do we need to do here?
    ... why should we shoe-horn our requirements into some existing
    ... that effectivley results in us creating a new spec that is
    subset of an existing spec (RFC)


      [19] http://lists.w3.org/Archives/Public/public-pkg-uri-scheme/ 

    Arve: We have defined our design goals

    <Marcos> ^^ me asking what we need to do

    TR: what happened with the manifest discussion yesterday?

    MC: we agreed to create a new spec for it but it may not be part of
    the Widgets spec suite
    ... minutes: [20]http://www.w3.org/2009/02/25-wam-minutes.html

      [20] http://www.w3.org/2009/02/25-wam-minutes.html

    TR: what is the status and roadmap?

    MC: see the minutes

    TR: what about http URI scheme?

    MC: we have several problems with that e.g. Origin may not make

    TR: having a manifest may add a layer of indirection that could help

    MC: doesn't solve the DOM node resolution prob

    <Marcos> <manifest xmlns="">

    <Marcos> <media path="" type=""/>

    <Marcos> <media ext="space delimited list" type=""/>

    <Marcos> </manifest>

    TR: I suggest looking at the manifest as a level of indirection that
    may help

    Josh: MHTML has a sec vulnerability that is not solvable
    ... serving from http: is not OK

    <Marcos> Josh: certs for SSL are not the same as code signing certs
    for widgets

    TR: is your concern Josh about cross-origin or in orgin pollution?

    Josh: I'm concerned about both
    ... are there any signed widgets in the wild today?
    ... how long will a cert last?

    MC: Konfab signs certs but I don't know how long they last

    <tlr> arve is right here

    <Marcos> arve: as mc said, lets not talk about sigs right now

    <tlr> the question is whether the indirection approach *can* work

    <Marcos> arve: we will return to that, lets just deal with URI
    resolution in the packaging spec

    <tlr> MHTML: [21]http://tools.ietf.org/html/rfc2557

      [21] http://tools.ietf.org/html/rfc2557

    <Marcos> scribenick: marcos

    <scribe> scribenick: Marcos

    <ArtB> ScribeNick: ArtB

    MC: what design do you recommend Thomas?

    TR: may have deviate from classical definition of Origin
    ... realize this doesn't make the problem easier

    MC: yes, agree
    ... it's the tiny issues that are creating problems with us

    TR: problem seems to be same origin policy
    ... may be able to use synthetic origins for files taken out of the
    ... I can send a strawman to the list
    ... I suspect you will have the same probs no matter what scheme you

    Arve: I don't think origin is relevant here

    MC: agree

    Arve: don't want to bind the resources in the package to something
    on disc

    TR: I understand you do not want an http server in the WUA

    MC: we want something like file: but not broken and evil

    TR: must distinguish between identity and retrieval
    ... you may not a new URI scheme but a way to determine base URI for
    starting resource
    ... and a definition of what happens to base uri if you deref
    something from the package
    ... if you assume base uri is a randon uri created for the running
    widget and the path begins with /

    [ missed TR's further statement ... ]

    <scribe> ACTION: Thomas submit your proposed model re URI scheme to
    the mail list [recorded in

    <trackbot> Created ACTION-315 - Submit your proposed model re URI
    scheme to the mail list [on Thomas Roessler - due 2009-03-05].

    TR: think about how to synthesize base URIs and how to resolve them

    MC: tag uri does indeed address the synthesis issue
    ... and our widget scheme defines the resolution part

    TR: is it a req that an existing web app can be put in a package and
    it just works?

    Arve: we think there is a different security model for widgets
    ... in some cases the security model must be stronger

    TR: I will write up my thoughts now and submit them to the list

    MC: I think this is a massive problem and was surprised BONDI has
    not done anything to address it
    ... we've spent two years on this

    DR: we should escalate this issue then

    Arve: BONDI File I/O api must address this

    DR: so what do we need to do to resolve this in a timely manner?

    MC: Josh would be the most ideal person to take this
    ... Josh - can you take this problem and make a proposal?
    ... I don't have the time to take this
    ... I think you Josh has the proper background to tackle this issue

    Josh: I don't think I can make a time commitment right now
    ... Do you want a requirements list?

    MC: yes

    <scribe> ACTION: Barstow send Josh the relevant pointers to
    facilitate his creating requirements for URI scheme [recorded in

    <trackbot> Created ACTION-316 - Send Josh the relevant pointers to
    facilitate his creating requirements for URI scheme [on Arthur
    Barstow - due 2009-03-05].

    AB: who from BONDI can help?

    DR: I'll take this back to OMTP

    <scribe> ACTION: Rogers determine a contact in BONDI that can help
    the WG work on a solution to the widget scheme [recorded in

    <trackbot> Created ACTION-317 - Determine a contact in BONDI that
    can help the WG work on a solution to the widget scheme [on David
    Rogers - due 2009-03-05].

    MC: the TAG has responded to all of our emails and created a new
    mail list for related discussions

    <tlr> marcos, what's that mailing list?

    MC: However, I'm not sure we have clearly documented our related
    requirements well enough to make our case to the TAG

    AB: package list is:

      [25] http://lists.w3.org/Archives/Public/public-pkg-uri-scheme/


      [26] http://dev.w3.org/2006/waf/widgets-reqs/#r6.-addressing- 
      [27] http://dev.w3.org/2006/waf/widgets-reqs/#r37.-resolve- 

    <Marcos> Timeless see ^^

    <tlr> ugh

    <tlr> R37 specifies a solution, not a requirement


    AB: P&C spec ...

    MC: I will try to get a new WD by March 9

    AB: will that be a new LC doc?

    MC: yes

    Arve: what is the expecation re open issue?

    MC: I expect all open issues to be addressed

    BS: so what is the theoretical earliest Candidate?

    AB: after we repond and resolve all comments from LC #2, we can then
    set a CR date
    ... any other comments about P&C?

    [ None ]

    AB: A&E spec ...

    Arve: trying to get a new WD published when we publish LC #2 of the

    AB: any comments on Arve's proposal?
    ... that's a very good target
    ... but what would that mean for the widget scheme
    ... is the widget URI scheme a separate spec?

    MC: yes

    AB: who is the editor of that spec?

    MC: Josh

    AB: did he agree to that?

    MC: I think yes

    <Marcos> Timeless, is that right?

    AB: OK, I'll talk to him

    MC: I am willing to be the Editor IFF someone provides the input
    [Hint to Josh]

    Arve: I don't want the scheme spec to be widgets-specific

    AB: anything else on the A&E spec?
    ... DigSig spec ...

    BS: I recorded LC #1 publication on 16 April

    AB: we are planning a new WD in March, right?

    MC: yes that is my expectation

    AB: I will follow-up with FJH

    BS: it would be best if it could be published by March 9

    AB: is Orange willing to help with some of the editing or test

    Mohammed: I will need to get back to you on that

    AB: Updates spec ...
    ... we didn't discus this spec during this meeting
    ... is Orange willing to help with the Editing and push that spec

    MC: after the P&C spec is published, I will start working on Updates

    AB: are any WG members willing to help with Updates spec?

    [ None ]

    AB: Window modes specs ...
    ... what is your understanding Marcos, regarding these two specs?

    MC: one will define the modes and their behavior
    ... Arve and I will co-Edit that one
    ... provided we get appropriate management support

    <tlr> folks, the meeting room isn't on the phone

    <tlr> otherwise you'd have heard Josh and me go through the URI
    scheme discussion

    MC: regarding the other spec, we need to discuss with CSS WG but I
    think I and/or Arve will be the Editor
    ... that 2nd one is tentatively titled "widget media query

    AB: can we say anything about FPWD for these two specs?

    Arve: I think these are both 3-5 pages


    AB: any volunteers to help with these two specs?
    ... can you say anything about FPWD dates for these two specs?

    MC: no, not now

    AB: anything else?

    BS: we have no pub date for the abstract scheme spec

    AB: we have no commitment for an Editor yet
    ... any volunteers to help with the abstract scheme spec?

    [ None ]

Guest Presentation

    AB: propose we end the meeting now
    ... any objections?

    [ None ]

    AB: any objections to the discussions by Scott et al being on the
    public mail list?

    [ None ]

    AB: Meeting Adjourned

Summary of Action Items

    [NEW] ACTION: Barstow send Josh the relevant pointers to facilitate
    his creating requirements for URI scheme [recorded in
    [NEW] ACTION: Marcos work with Arve to update the preferences API to
    reflect discussions on 26-Feb-2009 [recorded in
    [NEW] ACTION: Rogers create a proposal for OMTP members to supply
    Editor(s) for the Widgets specs [recorded in
    [NEW] ACTION: Rogers determine a contact in BONDI that can help the
    WG work on a solution to the widget scheme [recorded in
    [NEW] ACTION: Thomas submit your proposed model re URI scheme to the
    mail list [recorded in

    [End of minutes]
Received on Thursday, 26 February 2009 16:22:10 UTC

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