- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Thu, 26 Feb 2009 11:21:19 -0500
- To: public-webapps <public-webapps@w3.org>
The minutes from the February 26 Widgets f2f meeting are available at
the following and copied below:
<http://www.w3.org/2009/02/26-wam-minutes.html>
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
Approved.
-Regards, Art Barstow
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Widgets F2F Meeting
26 Feb 2009
[2]Agenda
[2] http://www.w3.org/2008/webapps/wiki/WidgetsParisAgenda
See also: [3]IRC log
[3] http://www.w3.org/2009/02/26-wam-irc
Attendees
Present
Art, Claudio, Ivan, Mohammed, Rainer, David, Arve, Marcos,
Benoit, Mike, Doug, Josh, Thomas
Regrets
Chair
Art
Scribe
Art
Contents
* [4]Topics
1. [5]Agenda Review
2. [6]Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs
Storage
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:
[13]http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/02
90.html
... where do we stand on this Marcos?
[13] http://lists.w3.org/Archives/Public/public-webapps/
2009JanMar/0290.html
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-attribut
e
[14] 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
[15]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
[16]http://www.w3.org/2008/webapps/wiki/WidgetsParisAgenda#API_and_E
vents_spec
[16] 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
[17]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
[18]http://www.w3.org/2008/webapps/wiki/WidgetURIScheme#tag:_URI_sch
eme
... 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/
WidgetURIScheme#tag:_URI_scheme
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>
[19]http://lists.w3.org/Archives/Public/public-pkg-uri-scheme/2009Ja
n/0000.html
[19] 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: [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
sense
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
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
[22]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
[23]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
[24]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:
[25]http://lists.w3.org/Archives/Public/public-pkg-uri-scheme/
[25] http://lists.w3.org/Archives/Public/public-pkg-uri-scheme/
<Marcos>
[26]http://dev.w3.org/2006/waf/widgets-reqs/#r6.-addressing-scheme
[27]http://dev.w3.org/2006/waf/widgets-reqs/#r37.-resolve-addressing
-scheme-to-uri-scheme
[26] http://dev.w3.org/2006/waf/widgets-reqs/#r6.-addressing-
scheme
[27] 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
Summary of Action Items
[NEW] ACTION: Barstow send Josh the relevant pointers to facilitate
his creating requirements for URI scheme [recorded in
[28]http://www.w3.org/2009/02/26-wam-minutes.html#action04]
[NEW] ACTION: Marcos work with Arve to update the preferences API to
reflect discussions on 26-Feb-2009 [recorded in
[29]http://www.w3.org/2009/02/26-wam-minutes.html#action01]
[NEW] ACTION: Rogers create a proposal for OMTP members to supply
Editor(s) for the Widgets specs [recorded in
[30]http://www.w3.org/2009/02/26-wam-minutes.html#action02]
[NEW] ACTION: Rogers determine a contact in BONDI that can help the
WG work on a solution to the widget scheme [recorded in
[31]http://www.w3.org/2009/02/26-wam-minutes.html#action05]
[NEW] ACTION: Thomas submit your proposed model re URI scheme to the
mail list [recorded in
[32]http://www.w3.org/2009/02/26-wam-minutes.html#action03]
[End of minutes]
Received on Thursday, 26 February 2009 16:22:10 UTC