Widgets F2F Meeting -- 26 Feb 2009

<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: http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0290.html
... where do we stand on this Marcos?

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: http://dev.w3.org/2006/waf/widgets-api/#the-preferences-attribute

[ 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 data);

<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 = localStorage.pageLoadCount;

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

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 data);

<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 meeting
... 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 http://www.w3.org/2009/02/26-wam-minutes.html#action01]

<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 http://www.w3.org/2008/webapps/wiki/WidgetsParisAgenda#API_and_Events_spec

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

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 fragmentation

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

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

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

DR: we'll keep our independent status

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

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

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

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 type)

<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 http://www.w3.org/2008/webapps/wiki/WidgetURIScheme#tag:_URI_scheme
... doesn't meet all of our reqs
... to create a new URI scheme is objectionable by the TAG

Arve: for: every scheme we have investigated has had at least one prob
... 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 scheme?
... that effectivley results in us creating a new spec that is subset of an existing spec (RFC)

<Marcos> http://lists.w3.org/Archives/Public/public-pkg-uri-scheme/2009Jan/0000.html

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

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

MC: doesn't solve the DOM node resolution prob

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: 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 package
... I can send a strawman to the list
... I suspect you will have the same probs no matter what scheme you use

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

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

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

<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: http://lists.w3.org/Archives/Public/public-pkg-uri-scheme/

<Marcos> http://dev.w3.org/2006/waf/widgets-reqs/#r6.-addressing-scheme http://dev.w3.org/2006/waf/widgets-reqs/#r37.-resolve-addressing-scheme-to-uri-scheme

<Marcos> Timeless see ^^

<tlr> ugh

<tlr> R37 specifies a solution, not a requirement

Schedules

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 P&C

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

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

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

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

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

Arve: I think these are both 3-5 pages

<tlr> YOU ARE NOT ON THE PHONE, JOSH IS.

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

- DRAFT -

Widgets F2F Meeting

26 Feb 2009

Attendees

Contents

Agenda Review

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

A&E Red Block Issues

BONDI and Widget Specs

Widget URI Scheme

Schedules

Guest Presentation

Summary of Action Items

Scribe.perl diagnostic output