- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Mon, 29 Oct 2012 17:55:29 +0100
- To: public-webapps <public-webapps@w3.org>
The Draft minutes from WebApps' October 29 f2f meeting are in
<http://www.w3.org/2012/10/29-webapps-minutes.html> and are copied below.
If you have any corrections, please send them to this list by November 5.
-Thanks, AB
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WebApps f2f Meeting
29 Oct 2012
[2]Agenda
[2] http://www.w3.org/wiki/Webapps/TPAC2012Meeting
See also: [3]IRC log
[3] http://www.w3.org/2012/10/29-webapps-irc
Attendees
Present
Art_Barstow, Josh_Soref, Bryan_Sullivan,
Odin_Hoerthe_Omdal, chaals, Julian_Aubourg, Adam_Klein,
jgraham, zcorpan, adrianba, Soonbo_Han, Wonsuk_Lee,
Jungkee_Song, Charles_McCathie_Nevile, Travis_Leithead,
Jonas_Sicking, Olli_Pettay, Simon_Pieters,
Maciej_Stachowiak, Lachlan_Hunt, Hallvord_Steen,
Kenji_Baheux, Bo_Hu, Bo_Chen, Arnaud_Braud,
Doug_Schepers, Eduardo_Fullea, Kris_Krueger,
Lars_Erik_Bolstad, Magnus_Olsson, Mike_Smith,
Mounir_Lamouri, Paul_Bakaus, Philippe_Le_Hégaret,
Rafael_Weinstein, Sakari_Poussa, Virginie_GALINDO,
Wayne_Carr, Yuan_Ji, Erika_Doyle_Navara,
Christine_Runnegar, Thomas_Roessler, Paul_Cotton,
Steve_Holbrook, Anne_van_Kesteren, Norbert_Lindenberg,
Robin_Berjon, Tobie_Langel, David_Grogan, Alex_Russell,
Brady_Eidson, kris_krueger, Larry_Masinter, Ryan_Sleevi,
Koichi_Takagi
Regrets
Chair
Art, Charles
Scribe
Josh_Soref, chaals, timeless
Contents
* [4]Topics
1. [5]Introductions
2. [6]Agenda Bashing
3. [7]Selectors
4. [8]Widget Updates
5. [9]editor orphaned specifications
6. [10]XHR
7. [11]Pub Status
8. [12]IndexedDB
9. [13]Web IDL
10. [14]Streams
11. [15]Web IDL
12. [16]Quota API
13. [17]Lunch
14. [18]IETF specs
15. [19]Introductions continued
16. [20]IndexedDB
17. [21]Push APIs
18. [22]Shadow DOM
19. [23]File * APIs
20. [24]File Reader API
* [25]Summary of Action Items
__________________________________________________________
<ArtB> Date: 29 October 2012
<ArtB> Scribe: Josh_Soref
<ArtB> ScribeNick: timeless
Introductions
chaals: welcome to webapps, everybody
[ Applause ]
ArtB: we're happy to be here
chaals: in IETF, they have the hum, we get the W3C clap
... this is a big meeting
... we're going to be really strict about making you Join
Queues
... and use the microphone
... I'm Charles
... the first thing i'm going to do is ask everyone to
introduce themselves
... say who you are, where you work, and if you have any
particular spec that interests you
... I'm Charles, I work for Yandex, i'm interested in just
about everything
shepazu: I'm Doug Sheppers, I'm one of 2 w3c staff contacts
krisk: Kris, Microsoft, testing
adrianba: Adrian Bateman, Microsoft, I'm interested
BO_HU_CHINA_UNICOM: Bo Hu, China Unicom, i'm interested in Push
API
Bo_Chen: Bo Chen, China Unicom, i'm interested in this WG and
related groups
ArtB: Art Barstow, Co-chair with chaals, Nokia, all specs
<npdoty> timeless: Josh Soren, from RIM, not yet a member of
the WG
pbakaus: Paul Bakaus, Zynga, everything that helps games
sicking: Jonas Sicking, Mozilla, all specs
<npdoty> from Zynga, everything that helps games
jaubourg: Julian Bourg, jQuery Foundation, interested in the
Web
mklein: Adam Klein, Google
rafaelw: Rafael W, Google, CCC
DDD: Wayne Carr, Intel, processors
Yuan: Yuan, Nokia, everything
EEE: EEF, Google, DOM Specs
FFF: FFG
GGG: GGH
morrita: HHI, Google, Web Components
JJJ: JJK
shan: Soonbo Han from LGE
spieters: Simon Pieters, Opera
<takuya> tatakuya from Google. IME API
<bryan> Bryan Sullivan from AT&T, co-editing the Push API spec,
AC rep, interested in most specs but especially storage specs
and File* specs
odinho_: Odin, Opera, interest in most specs, but listens most
carefully for IndexedDB atm
Lachlan Hunt, Opera, editor of Selectors API
<jgraham> jgraham: James Graham, Opera
<KenjiBX> KenjiBX ; Kenji Baheux ; Google ; general interest in
WebApps spec ; particular interest in proposed IME API.
<haraken> haraken from Google. DOM specs.
bryan: bryan Sullivan, AT&T AC Rep, MM
paul: Paul Cotton, Microsoft, HTML co-chair
PPP: PPU
yoske: QQQ
RRR: RRA
Koichi Takagi: KDDI, Japan
<efullea> efullea: Eduardo Fullea, co-editing Push API spec
tomoyuki: Tomoyuki from KDDI, Japan
TTT: TTU
<efullea> efullea: Eduardo Fullea, Telefonica, co-editing Push
API spec
amirabella: Anthony Mirabella, Synacor
<Oh> Jong Soo Oh, LGE
wseltzer: Wendy Seltzer, W3C
christine runnegar: Internet Society, Privacy Interest Group,
Provenance WG
<amirabella> s/Amira Bella, CDE/Anthony Mirabella, Synacor/
CDH: CDJ
CDK: CDL
<a12u> Hiroyuki Aizu, TOSHIBA , interested in Web components
and WebIntents
jfmoy: France Telecom
CDP: CDQ
BEF: BEJ
<krisk> www.w3.org site is down...known issue w3c staff working
on this...
Travis: Travis Leithead, Microsoft
chaals: so, now you've forgotten everyone's name
... please say your name before speaking
... scribe has certainly forgotten your name
Agenda Bashing
chaals: i'm going to try to break the agenda into blocks of
less than an hour
... so we can have short breaks of 5-10 minutes
... trying to talk (or scribe) for 2-3 hours is a bad idea
<hallvord> If my introduction wasn't logged, here it is:
Hallvord R. M. Steen, Opera Software, XMLHttpRequest co-editor
/ Clipboard Events editor
<bryan> anyone else having issues with the W3C wiki server?
chaals: items: webidl
... streams
... input method
... push api
<sgodard> No access to W3C wiki server :(
chaals: indexeddb
<krisk> yes w3c.org site has issues (timesout)...staff working
to resolve
chaals: web intents
... will be tomorrow afternoon just before 5
... web components (shadow dom, templates) is set for 3:45pm
today
... i'm presuming we have people dialing in for that (i.e.
fixed time)
... file api, 4:45pm today (again, people dialing in, fixed
time slot)
... does anyone have a topic that is not on that list?
... that you'd like discussed
bryan: i'd like to take push api today (before file), or
tomorrow morning
... like 3pm?
chaals: objections?
[ none ]
shepazu: webidl is a pretty long discussion
... i think we should revisit it later in the day
chaals: so split it into two sessions?
... Travis , i think you have a guy on the hook for that
ArtB: plh , you should be here for that
... do you have time constraints?
plh: don't put it tomorrow afternoon
chaals: web idl next, and then revisit after lunch
shepazu: i'd like to touch base w/ heycam, so tomorrow morning
chaals: streams, time constraints?
... streams will be merged file api discussion this afternoon
... IME... anytime
... process, web idl-1, ime, indexeddb
... as time allows
takuya: i'd like to push IME to this afternoon or tomorrow
chaals: tomorrow morning
... webidl-2, ime
mjs: Maciej, Apple
... there's been discussion on the ML about File System API
... either taking it off standards track
... or...
chaals: i expect it to be part of the file api discussion
... i'll toss in a topic
... i think we should look at AppCache, Offline Applications,
... mess
... html wg has AppCache in their spec
... everyone hates it
... either because they've implemented it
... we have a proposal from Mozilla for packaging applications
using JSON instead of XML
... all of this deals w/ using applications offline
Lachy: lachlan, Opera,
<npdoty> +1 on talking about all of these offline questions at
once
Lachy: when we do Selectors, can we cover Selectors api 2?
<bryan> +1 to manifest discussion and appcache
Lachy: we'll have a chance to repeat this process tomorrow
... if you've forgotten to mention something, that's bad, but
we can fix tomorrow
... we have a small handful of process things
... if you want to talk about how w3c process works/how it
should be changed
... this isn't the venue
... we don't care
... w3c has a CG for that
... right now we work w/ the process we get
... in walks anne
... our goal is to get docs to REC
<sgodard> ArtB, it's not just you
Lachy: there's a handful of documents we're trying to step
through that
... Selectors API 1, Widget Update
... there's a set of docs where we need editors
Selectors
chaals: we have a specification for Selectors Level 1
... we have a test suite, recently revised
... there was a CfC to move to PR
... the normal process is we say does everyone agree to move
along
... we prefer positive responses
... there was only one response
... did anyone want to speak?
[ No one ]
chaals: Lachy changed the test suite
... did anyone review it?
Lachy: i rewrote the test suite
... the old one was full of bugs
... and wasn't revealing bugs in implementations
... i rewrote it, it now shows bugs
... on the spec, i removed hasFeature()
... it's now irrelevant from the latest DOM spec
chaals: we think Selectors API level 1 is ready to go
... we can declare victory as soon as we've filled in the
boxes/forms/done the process
Widget Updates
chaals: widget updates has sat around for a while
... in a PAG for a while
... there are a couple of implementations
... i'm curious to know if there are more implementations
... Opera has an implementation shipping
<Lachy> Selectors API Testsuite:
[26]http://dev.w3.org/2006/webapi/selectors-api-testsuite/
(Level 1 tests need review, level 2 is a work in progress.)
[26] http://dev.w3.org/2006/webapi/selectors-api-testsuite/
chaals: with a backend
... Apache has an implementation
sakari: the Tizen project has implemented it
sebastian: we use it
chaals: objections to moving it forward?
[ None ]
editor orphaned specifications
chaals: DOM4, URL Spec
<ArtB> ACTION: Charles start the process to move Widget Updates
to Candidate Recommendation [recorded in
[27]http://www.w3.org/2012/10/29-webapps-minutes.html#action01]
<trackbot> Created ACTION-664 - Start the process to move
Widget Updates to Candidate Recommendation [on Charles McCathie
Nevile - due 2012-11-05].
chaals: we're committed atm to do them
... there's someone working on these things
... it would be interested to know what his perspective is
annevk: i'm moving them forward
chaals: but you're not doing them in w3c
annevk: that's correct
... i'm talking with w3 shortly
... about being an invited expert
chaals: our current perspective is that we'd like an editor for
DOM4
Lachy: i might be able to be an editor for dom4
chaals: url?
... URL isn't a very big spec
... you can copy+paste what anne does
... put your name on it
... become famous
... it's really easy
ArtB: fame and fortune will follow
shepazu: guaranteed
ArtB: if you don't want to volunteer publicly, that's fine,
talk to chaals or ArtB
chaals: Progress Spec is more or less done
... volunteer to do that spec
... shepazu will thank you
XHR
chaals: XMLHttpRequest
hallvord: we think the spec is pretty feature complete
... we're trying to get overview of test coverage
<krisk> Microsoft submitted some more tests for XHR
[28]http://dvcs.w3.org/hg/webapps/rev/be00d20f652e
[28] http://dvcs.w3.org/hg/webapps/rev/be00d20f652e
hallvord: and the changes anne has done to the spec
jaubourg: that pretty much covers it
chaals: are there significant changes to the spec?
annevk: progress was ported in
... it was aligned with refersrc in html
<odinho_> [29]https://github.com/whatwg/xhr <- XHR spec annevk
[29] https://github.com/whatwg/xhr
<annevk> [30]AnonXMLHttpRequest XMLHttpRequest(anon=true)
[30] https://github.com/whatwg/xhr/commits
<annevk> 308 is now mentioned
<annevk> Encoding Standard is integrated
<jgraham> [31]https://github.com/whatwg has url and dom also
[31] https://github.com/whatwg
<annevk> user/password are now always okay
hallvord: i think there's some work for mapping
... and then try to ship it
... the main work is test coverage/mapping implementation
... and trying to ship the spec
annevk: there's a few more things
... canceling the send/abort algorithms
... needs to be rewritten to use a flag
... the current way doesn't work
... you always want to dispatch certain events
... it needs to be updated to use the url standard
... to reference things with spaces in them
... and we need to write tests for these conditions
chaals: should you be able to play around w/ various headers
... lots of people wanted to be able to add/change the UA
header
... we ended up not making a change
hallvord: we're still trying to figure out if we'll make a
decision
chaals: there are people who want to be able to change it
sicking: there's also the AnonXMLHttpRequest constructor
... i don't think it's been implemented
... we've proposed an alternate syntax
... that also allows for http headers
hallvord: that's one of the things to pick annevk 's brain
<Zakim> adrianba, you wanted to ask about Stream
adrianba: annevk did some changes recently
... for accessing Streams
... we're specifically interested in
... for the new media specs in the HTML WG
... we could talk a bit more about this under stream
... but we'd like to talk about that a bit more here
odinho_: Opera implements AnonXMLHttpRequest
... but we have no problem changing it
... we like the new proposal better
... so it won't be a problem
chaals: thanks SK telecom
... who made a commitment for RF
hallvord_: on streams
... i guess we could put that in the next version
... since we want to ship this spec
... no one's implemented that
... so i hope it's possible to defer that
adrianba: we implemented and shipped it in ie10
... with a prefix
... i'm fine with deferring it
... provided it's written somewhere that we can reference
chaals: was that you volunteering to write it?
adrianba: i didn't hear that
... but sure
chaals: he agreed
... xhr level 2
... the plan is to get the one we have finished
... and then work on the next one
<adrianba> [32]http://www.w3.org/2008/webapps/wiki/PubStatus
[32] http://www.w3.org/2008/webapps/wiki/PubStatus
Pub Status
ArtB: CORS
<sgodard> +1 w3.org is ok now
ArtB: are the webappsec folks here?
tlr: my recollection is that BradH is driving this
... trying to get it ready
... bradh is in the room here
<annevk> (latest commit to CORS is mine...)
chaals: my memory is they're LC/CR
<annevk> (W3C CORS that is)
tlr: it's LC, comment period has closed
... think we have an email for one issue
chaals: Clipboard
hallvord_: it's something i should get back to
chaals: anyone want to assist
hallvord_: i think the remaining issue is onbefore*
<npdoty> webappsec is meeting Thursday/Friday, fyi
hallvord_: for integrating copy with native browser
<tlr> on CORS:
[33]http://www.w3.org/mid/370C9BEB4DD6154FA963E2F79ADC6F2E2AB22
A@DEN-EXDDA-S12.corp.ebay.com
[33] http://www.w3.org/mid/370C9BEB4DD6154FA963E2F79ADC6F2E2AB22A@DEN-EXDDA-S12.corp.ebay.com
<annevk> WHATWG CORS had a few changes:
[34]https://github.com/whatwg/fetch/commits
[34] https://github.com/whatwg/fetch/commits
hallvord_: i have a request from university of geneva
... i was considering ducking it
... but chromium was interesting
<tlr> avk, do you know if Brad was tracking these?
<annevk> to account for 308, some typos, Referer control
chaals: we'll use them in yandex
<annevk> tlr: no commits have been made to the W3C copy for 4
months
ArtB: so we're one feature/issue from LC
hallvord_: sort of
... one feature is missing
... there's some text about security
<tlr> what's the nature of your changes?
hallvord_: and cleaning up of content
... which we should remove
... perhaps it isn't necessary
ArtB: if people want to see that spec move forward
... they should submit comments
hallvord_: one issue to add, one to remove
chaals: if people are worried about security, look at it,
scream
... DOM4
... we're looking for an editor
<npdoty> does someone want to chat over coffee about Clipboard
and security/privacy?
chaals: dom level 3 events
Travis: dom level 3 events is
... has exited its second LC
... 30 of September
... there were a short number of LC comments
... 7 or 8
... recorded in a DoC
... i think the majority of those comments have been addressed
... in comments or email
chaals: people have been asking for features
... but that should be dom4
Travis: to continue
... i'd like to transition those to dom level 4 events
... to allow the mind share to continue to progress
... while we step aside and lock down dom 3 events
... i'd like to propose that we organize those features into a
separate document
... and publish that as FPWD
<hallvord_> event.key is still a problem child, authors trying
to use it have been complaining both to me and on the mailing
list
Travis: i can take an action
... next step for D3E
... is move to CR
<ArtB> ACTION: Travis create an ED of DOM4 Events [recorded in
[35]http://www.w3.org/2012/10/29-webapps-minutes.html#action02]
<trackbot> Created ACTION-665 - Create an ED of DOM4 Events [on
Travis Leithead - due 2012-11-05].
chaals: dom parsing and serialization
Travis: also me
<ArtB> ACTION: Barstow work with Travis on a CfC for DOM3
Events Candidate [recorded in
[36]http://www.w3.org/2012/10/29-webapps-minutes.html#action03]
<trackbot> Created ACTION-666 - Work with Travis on a CfC for
DOM3 Events Candidate [on Arthur Barstow - due 2012-11-05].
Travis: i'm c+p from ms2ger
... that's the status
<hallvord_> (should I ask for the mike and comment even if I've
"said" something on IRC?)
chaals: file stuff we'll talk about this afternoon
... fullscreen
... we sort of have an editor
... tantek, he's in CSS, it's a joint deliverable
<npdoty> q/
chaals: i believe that if we bribe him, he'll produce drafts
... gamepad
... any editors here?
... html templates, indexeddb, ime,
... webidl
... heycam, where is java bindings for webidl?
... pointer lock, progress events
<heycam> [37]http://dev.w3.org/2006/webapi/WebIDL/java.html
[37] http://dev.w3.org/2006/webapi/WebIDL/java.html
chaals: push api for later
... is the quota management editor here?
... server sent events?
ArtB: server sent events LC published last week
<heycam> I have kept the Java bindings document up to date with
Web IDL, but I expect just to publish it as a note for
curiosity at some point.
ArtB: two more weeks of review
<takuya> For Quota, I can follow up with its editor (Kinuko)
later.
ArtB: if we have no major issues raised
... we can move forward
... we need a test facilitator
... i know there are tests from opera
... any volunteers for facilitator?
... jgraham ?
jgraham: maybe
... we moved the tests from opera's server to github
<hallvord_> welcome Jungkee :)
jgraham: anyone else w/ tests for Server-sent-events, please
talk to me
<Jungkee> Hi Hallvord
chaals: testing is something we'll come back to in the agenda
<Jungkee> Hi Julian
chaals: lots of work that needs to be done
... it's great to contribute one test
... it's amazingly helpful to be the facilitator for a spec
... shadow dom is on the agenda
... screen orientation
mounir: mounir, mozilla
<ArtB> ACTION: barstow follow up with Kinuko Yasuda on status
and plan for Quota Management API [recorded in
[38]http://www.w3.org/2012/10/29-webapps-minutes.html#action04]
<trackbot> Created ACTION-667 - Follow up with Kinuko Yasuda on
status and plan for Quota Management API [on Arthur Barstow -
due 2012-11-05].
mounir: screen orientation in Firefox for Android and B2G
... i heard from someone from google
chaals: stream api is on the agenda
... url we're looking for someone
... web app manifest is on the agenda
... web components is on the agenda
... webidl is on the agenda
... web intents is on the agenda
... web messaging
krisk: there's a good number of tests
... if we move them from web workers to web messaging
... it could be sufficient to be complete
chaals: web sockets
ArtB: CR was published last month
... question of interop for exit criteria
<jgraham> server sent events tests -
[39]https://github.com/w3c/event-source
[39] https://github.com/w3c/event-source
krisk: last F2F we talked about arraybufferview and replacement
character
... ie10 implements that
... we also talked about event constructors
... all 3 are issues
... i sent an email about the test server
... there's an issue w/ getting the server working for the
tests
ArtB: there's a request for review of the test suite
... no comments on the test suite implies that the test suite
is sufficient
<odinho_> RRSAgent: make minutes
ArtB: so we wait for implementations to catch up
chaals: who has impls?
... opera does?
SimonPieters: opera has it
sicking: i think we implement the spec
... i think we do replacement character
... and arraybufferviews
... i'm fairly sure we do event constructors now
chaals: sounds like it's being implemented
IndexedDB
chaals: just a small matter of getting it cooked
... web storage?
ArtB: it's been around for a year now
... waiting for implementations to catch up
... i need to contact Jong-Heun Lee
chaals: web workers?
ArtB: published in may
... for shared workers, i think we're lacking impls
SimonPieters: there are tests
... the opera submitted tests aren't all testharness.js
... i'm not sure about pass rate on different browsers
... test suite still needs more work
chaals: any big issues?
sicking: i'm pretty sure there are pretty big features not
implemented by anyone
... we don't implement shared workers
... i don't know if anyone implements workers in workers
annevk: i think opera does workers in workers
Travis: IE10 has workers
<annevk> Opera did it first1
Travis: we don't support shared workers in any form
... with the possible exception of automatic GC
chaals: so outstanding work to be done
ArtB: is it small
... should we split the spec?
chaals: does anyone suggest we should split the spec?
Travis: i'd like to entertain the idea of splitting out shared
workers
... as a separate spec
... wanting to gauge support for that idea in the group
... seems like a good idea to move workers forward since
everyone has it
chaals: we entertain spec editors
SimonPieters: i think we shouldn't split the spec
... no one is not planning to implement
pbakaus: i have a question on this
... i had recent discussions on new features
<ArtB> ACTION: barstow work with Jong-Heun Lee to start a RfR
Web Storage test suite [recorded in
[40]http://www.w3.org/2012/10/29-webapps-minutes.html#action05]
<trackbot> Created ACTION-668 - Work with Jong-Heun Lee to
start a RfR Web Storage test suite [on Arthur Barstow - due
2012-11-05].
pbakaus: i wonder where we put them
... do we put them in a new spec?
chaals: anyone know Hixie 's view?
jgraham: Hixie will just put it in the WhatWG spec
... he won't split it out
... whether it makes sense depends on the feature
... if it ties in and affects semantics
... it might be hard to put it into a separate document
... without lots of hooks and making it fragile
sicking: one feature is sync message channels
... which ties in pretty deeply
pbakaus: we discussed canvas
chaals: i don't see this as support for splitting it out
... ArtB does the process puKinukos
... you're welcome to volunteer
... but at some point we'll be skeptical about you volunteering
for more work
... if we take what we have through the process
... we expect another version in the future
<takuya> Re; WebSocket support, Chrome has also supported it
for long time but arraybufferview and replacement character
haven't been implemented yet.
chaals: we have widgets for tomorrow
... time for a 10 minute break
[ Break ]
Web IDL
<takuya> Correction regarding websocket support in chromium, we
have already implemented both (arraybufferview and replacement
character). sorry about it.
chaals: half the people asked about webidl now asked for it to
be postponed
Streams
<adrianba>
[41]http://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm
[41] http://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm
adrianba: we updated the streams spec last week
... it's a pretty simple spec
... we made some changes to align it with changes in the
fileapi
... the stream object maps fairly closely to the Blob object in
fileapi
... stream has a way to keep reading data until you get to the
end of the stream
... there's a streamreader that maps fairly closely to
filereader
... there's a streambuilder which is fairly close to what we
used to have with blobbuilder
... it doesn't make sense to move to the constructor form
... so it's still there
sicking: can you read from a stream multiple times or just
once?
adrianba: you can only read the data once
... the stream reader methods have a construct to say the
maximum amount of data you want to read
... so you can avoid reading to the end
... you could read into a blob
chaals: so i could read from a stream into a blob
... and then read from the blob multiple times
adrianba: or into a string
sicking: is there a wa to get a stream that represents the
content of a url?
adrianba: part of the proposal in the stream spec
... which i think i've now volunteered to write into a
different spec
... in ready-state-3
... if you set the response type to stream
... then you can put it into a stream object
... and essentially read off the wire from xhr
... and at the end the xhr moves to ready-state-4
sicking: is there the concept of a stream failing?
... if the server fails instead of ending
adrianba: if you call a read method
... and the read is ending because of an io error
... then the method throws an error
... the same sort of error construct as in file reader
... we have the stream builder and the stream reader from xhr
... we have discussions in html wg for media source extension
spec
... we'd like to use the stream object from xhr
... to hand off data from media to the rendering pipeline
... we the Media Group
sicking: how does that work if you can only read from a stream
once
... given that a media might want to rewind
adrianba: this is for media stream
... where you can append to a buffer
... the media stream is then responsible for managing that
buffer
... we want to avoid having to read all the way to the end into
an array buffer
... and then copy it into the media element buffer
... this avoids copying into another buffer
<Zakim> timeless, you wanted to ask if you still get those last
bytes before the exception
adrianba: you can read the data during progress events
... and then get the error later
... as with progress events/file
SimonPieters: with file we dropped blob builder
... is there a plan to do the same thing with stream?
adrianba: no, with blob you have all the data available at the
time it's created
... the blob is immutable
... for stream, the stream builder lets you create an instance
of a stream
... but still have a reference to the builder
... to feed in more data
... to append to the stream
... maybe sending with xhr, or consuming from some place else
SimonPieters: wouldn't it make sense to just have an append()
method on the stream?
adrianba: this allows for producer-consumer in different places
... workers
... so you can transfer the object
... i'm open to discussion
... we haven't built builder yet
SimonPieters: discuss on bug/ML
sicking: if you want to stream from URL to <Media>
... you need to be able to Fast Forward
... without wanting to read all the data in the interim
... and you want to be able to rewind
... you want to be able to jump arbitrarily
adrianba: the intent is to hook it up to the media source
extension
... which lets you programatically compose the buffer
... for adaptive streaming
... you'd have a manifest file
... pointing to different segments at different bitrates
... i compose an xhr for one segment
... and choose a different bitrate for another segment
... the buffer in the media element holds the segments you
append/insert
... the buffer can drop parts
... the media element with the extension will tell you if you
need the data
chaals: so you could rewind to a segment you've been to
... and you could choose to pull in a different quality
(higher) for the segment
sicking: i think my question is more on media stream
chaals: how long will it take for you to build this? will this
be in ie11/ie12?
adrianba: we built a large part of this already
... we're looking for feedback... as SimonPieters mentioned
... is this the right model
... are there more changes in the file api
... that we'd need to reflect here?
... we feel read part is more useful than builder
... which is why we did that
chaals: do you have someone doing the builder part?
adrianba: you can get a stream from xhr
chaals: is anyone doing builder side?
... break for 30 minutes
[ break ]
Web IDL
<chaals> Agenda planning for the rest of the day:
<chaals> + Web IDL
<chaals> (11.15 − 12.15)
Travis: webidl overview... and then testing
... there's a v1 spec
... which heycam forked off earlier this year
... he's currently working on v2 of webidl
... where new proposals, iterators, serializers have been
placed
... in the interest of finishing v1, he did that split
s/present +/present+ /
Travis: there are a number of specs with normative references
to webidl
... and they'll get stuck at CR until v1 moves to REC
... there are two approaches
... we create a test suite for the web idl specification
... that tests every normative feature in the specification
... by searching across specifications to find occurrences of
those features
... to test those features specifically
... for interface object testing, we'd select a couple of those
snippets
... test to see if they're present
... not testing the syntax of webidl
... testing the binding
... so if you're building a browser that supports webidl
... you'd have to implement those things
... it's a bit dicey, since the test suite builders have to
pick interface sections that everyone would implement
... the second approach
... would be to create a meta test suite
... "how to test your specification test suite"
... two examples
... the selectors api spec
... the web navigation timing spec (in the web perf wg)
... both of those specifications reference webidl normatively
... and they'd like to go to REC
... if i'm building a test suite for navigation timing
... what do i test?
<Zakim> odinho_, you wanted to ask about
[TreatUndefinedAs=Missing]
odinho_: we can talk about that later
Travis: i think there's a slot for that in v2
chaals: this discussion is about stabilizing/publishing v2
mjs: is there at least one spec identified for every feature of
webidl
... that is likely to be widely implemented
... and a good example of that feature
Travis: good question
... there's a type called Byte
... prior to yesterday, i wasn't aware of any spec using it
... i found one yesterday, khronos's Typed Array spec
... i believe there's an instance of each feature
... but not necessarily all combinations
... clamp(...various types...)
mjs: is there a list of specifications to use for targeting
Travis: i've created a webidl test
<shepazu> there is also this page, for some references
[42]http://www.w3.org/wiki/Web_IDL
[42] http://www.w3.org/wiki/Web_IDL
Travis: that's loading web idl assertions in iframes
... there's no summary of "these are the specs i'm taking from"
... but they're implicit
jgraham: i don't know how relevant it is to testing webidl
itself
... there's IDLHarness.js
... in the resources repository
... in dvcs
... it might be helpful
[43]http://dvcs.w3.org/hg/resources/file/tip/idlharness.js
[43] http://dvcs.w3.org/hg/resources/file/tip/idlharness.js
jgraham: it will try to test the implications of webidl
plh: last i tried, it failed on the window object
SimonPieters: i think there changes to webidl
... AryehGregor wrote it
jgraham: I think AryehGregor plans to work on it
<krisk> Here is a test that consumes this idlharness.js
<krisk>
[44]http://www.w3c-test.org/html/tests/submission/AryehGregor/i
nterfaces.html
[44] http://www.w3c-test.org/html/tests/submission/AryehGregor/interfaces.html
jgraham: it uses head grabber that darobin wrote
... if things don't match that, it'll fail
... i think that's out of date and needs to be updated
Travis: assuming that worked
chaals: say we identify "this piece is used in Selectors API"
... using this tool to check whether this works
<chaals> ?
<chaals> MJS: Seems like there are 3 testing issues:
<chaals> … the combination of IDL and a particular spec, plus
what IDL says, implies requirements on that spec.
<chaals> … eg notification has IDL snippets and that implies
requirements for the behaviour of those interefaces.
<chaals> … Maybe every spec using IDL should include tests for
the parts of WebIDL used in the given spec.
<chaals> … But also, IDL needs to be tested itself. It has
requirements on other specifications, but it is hard to make a
test suite that tests specs.
<chaals> … But we could do a grammar-level check, and say that
satisfies spec confromance. But tehre are also requirements
that cascade down to user agents, and the question is how
totest those for WebIDL?
<chaals> … So let's find specs that show examples of each item,
and test them. This harnes could help us do that.
<chaals> … We satisfy the larger set of test suites, and those
results let us confirm that WebIDL itself works.
<chaals> … If we trust the harness we can use it to automate.
<chaals> … the process.
<chaals> CMN: +!
<chaals> Travis: We could make the test harness into the
testing deliverable, and agrees that is sufficient.
<chaals> MJS: Interesting because that would let you test
combinations. SUper useful but not sure it fulfils the testing
requirement if the harness hasn't actually been used to do the
testing yet.
<chaals> TL: How do we test the harness.
<chaals> CMN: Don't think we can get away with just the
harness. Wwe need to run it, as Maciej said, but that doesn't
seem to be the hard part. Agreeing on the harness seems OK.
<chaals> TL: If I edit a spec and test suite fails on WebIDL,
is that a problem?
<chaals> JG: We should be allowed to say a test is failing for
a reason other than the actual test itself.
chaals: our obligation is to prove that this is implementable
and workable
... we can prove that
... we want to avoid the situation where we say "this is fine,
it'll work some time in the future"
... it's like saying "we'll fail the selectors api because
someone has a bug in target()"
<plh> -->
[45]http://w3c-test.org/webperf/tests/submission/W3C/Navigation
Timing/test_interface.html
[45] http://w3c-test.org/webperf/tests/submission/W3C/NavigationTiming/test_interface.html
chaals: i certainly expect to do that
<Lachy> s/target()/:target pseudo-class/
<chaals> … waiting to fix all corner cases is broken, and we
can be more grown-up
SimonPieters: having reference to non-REC
... it doesn't block moving to REC
<chaals> CMN: Right. We're not going to hang up on tests that
fail for some non-relevant reason.
SimonPieters: you just have to inform that directory
... it doesn't necessarily block you
mjs: w3c process does require that you state your CR exit
criteria
... it doesn't require "two implementations will pass in the
test suite"
... a spec could state "as long as webidl issues are
identified, we won't block on them"
<shepazu> +1 to mjs
mjs: CR exit criteria saying "we must have fixes for every
single observed issue" isn't a good idea
plh: i did this exercise with web performance navigation timing
... I did this exercise
... And every single thing had issues
Odinho: I did testing and stopped there was too much red
... There was no prioritization
... Throwing is important
... Some things are less
... Prototype chain
Travis: hopefully when webidl is pushed to rec, people will fix
their implementations to match
<chaals> TL: If there are crucial parts of WebIDL that need to
pass we need to make sure they do...
Travis: so that we won't have 80% failures for indexeddb
mjs: i've heard there are things which are tested and fail
... i'd like to know what they are
... it's hard to talk in the abstract
... are these different in all browsers?
... or do the browsers all do one thing which is distinct from
webidl
... in which case we could "fix" webidl
... but if the browsers each have different behaviors, then
making them match webidl could be easier
jgraham: for a lot of the things
... where we see lots and lots of fails
... it's the way the testharness has been written
... it's to test the webidl stuff very carefully
... we can't say nothing about it
... but atm, we have 4 browsers doing 4 distinct things
... where should attributes be on the prototype chain?
... on the objects, on the prototype, both?
... we discussed it on the ML
... we agreed it was the right solution technically
... but everyone who isn't doing that today needs to change
this, it's tedious
... but that shouldn't block specs
Lachy: priotizing tests
s/prio/priori/
scribe: i have critical tests
... and nice to have tests
<hallvord> It's important to get those prototype chain issues
worked out - or we get compat problems like
[46]http://my.opera.com/hallvors/blog/2012/10/26/microsofts-sky
drive-gun-meet-foot
[46] http://my.opera.com/hallvors/blog/2012/10/26/microsofts-skydrive-gun-meet-foot
scribe: including stuff in webidl that might fail
... changing some parts in webidl would require changing lots
of things in our implementation
... and we didn't have the resources for that
... implementing TypeError / NSError from firefox
... changing that, it's in our code, it's a relatively small
change
... but it can affect lots of things
... requiring a lot of test fixes in our system
sicking: there are very few controversial things
<chaals> +
sicking: there's very few cases where we should remove
something from the spec
... it's just tedious to fix
... and doesn't add value for implementers
... so it gets less priority
mjs: it'd be useful to make a list of known common things
... where there aren't 2 implementations matching webidl's spec
... if the harness could group things
... based on which type of interop issue
... that'd be useful
... thus the remaining ones would be more easily identified
... for the n different behaviors of attribute behaviors
... i'd like to know what they are
sicking: three behaviors i know of
... webkit puts stuff on object itself
... i think opera puts things on the relevant prototype object
... for dom node nodeName, on the Node interface object
... gecko puts it on the Node interface object and the leaf
interface object
... e.g. Node and Div interface
Travis: IE since 9 puts it on the Node prototype
jgraham: opera is different for Methods and Attributes
<SimonPieters> in Opera methods are on the prototype,
attributes are on the object.
Travis: i'll take an action as we build the test
... to understand the impl report
... there's 2/3 here
... it sounds like that'd be helpful for further discussion on
issues
chaals: if you build stuff on webidl
... and you change the spec underneath them
... that makes a mess for really hard to change things
... things outside web browsers
... we need to think about pragmatic
... a way of testing downstream specs
... and finding out what the issues are
... having a WG lets us discuss how to break each of everyone's
systems to reach interop
... seems we have a path forward
<smaug> plh: to nav timing? I recall one change + webidl-fying
the implementation
ArtB: plh , do you know what to tell the web performance group?
timeless: Nightly has 45 pass (2 fail)
... ie9 has 42 pass (5 fail)
plh: i can take that to the director
chaals: an answer to how long does it take to get done
... there's a priority problem
... "until web idl is finished, you have more work to do"
... to be sure that webidl isn't going to change under you
<krisk> IE10 has the same result as IE9 (42 pass, 5 fail)
chaals: go back to groups "you should push web idl to be sure
it's finished sooner"
plh: those groups don't know how to test webidl
chaals: i see darobin 's boss looking at darobin
darobin: i'm coding it right now
Travis: i'd propose we send out a general announcement
... "if your spec depends on webidl. please contact Travis "
... "we'll see if we can prioritize your pieces of webidl"
plh: we have a few specs in PR waiting on WebIDL
<ArtB> ACTION: barstow work with PLH on an announcement seeking
IRC fragments [recorded in
[47]http://www.w3.org/2012/10/29-webapps-minutes.html#action06]
<trackbot> Created ACTION-669 - Work with PLH on an
announcement seeking IRC fragments [on Arthur Barstow - due
2012-11-05].
plh: including GeoLoc
<ArtB> s/IRC fragments/Web IDL fragments/
chaals: on getting WebIDL stable, anything else we need to add?
... we have a plan
... find out what we don't agree on, work on making them work
Travis: please review the assertions in webidl
[48]http://dev.w3.org/2006/webapi/WebIDL/WebIDLTest.htm
[48] http://dev.w3.org/2006/webapi/WebIDL/WebIDLTest.htm
ArtB: i can send out a call for review to public-script-coord
chaals: time check
<ArtB> ACTION: barstow start a Call for Review for Web IDL test
plan on public-script-coord [recorded in
[49]http://www.w3.org/2012/10/29-webapps-minutes.html#action07]
<trackbot> Created ACTION-670 - Start a Call for Review for Web
IDL test plan on public-script-coord [on Arthur Barstow - due
2012-11-05].
ArtB: the guys working on Quota API could give a quick update
Quota API
UNKNOWN_SPEAKER: she received two pieces of feedback
... temporary/permanent
... the other was to change the interface name
... to get the object instead of integer
... Kinuko mentioned changing temporary/permanent
... as far as she knows, chromium is the only browser
supporting this api
... to move forward,
... she's eager to look at how to get others to associate
things with
[ .... ]
tobie: vaguely, i made those comments
timeless: he isn't an implementer, he's a consumer
Lunch
chaals: 75 minutes for lunch
... be back here, 1:30 Central European Standard Time
MikeSmith: will the room be locked?
chaals: MikeSmith will find out
MikeSmith: if people want to leave stuff, we can lock the room
<ArtB> ACTION: barstow work with Opera Websocket tester(s) on a
Request for Review of their web socket tests [recorded in
[50]http://www.w3.org/2012/10/29-webapps-minutes.html#action08]
<trackbot> Created ACTION-671 - Work with Opera Websocket
tester(s) on a Request for Review of their web socket tests [on
Arthur Barstow - due 2012-11-05].
<kotakagi> s/Koichi Takagi/kotakagi/
<aizu> Present Hiroyuki_Aizu
chaals: it's getting on towards the 1:30pm start time
<sicking> supercalifragelisticexpialidocious
s/supercalifragelisticexpialidocious//
<smaug> shadows
s/shadows/
<ArtB> s/Present Hiroyuki_Aizu/Present+ Hiroyuki_Aizu/
<slightlyoff> OH HAI
chaals: anything else people want to talk about?
lmastiner: will you talk about URLs?
chaals: we're looking for an editor to rebrand annevk's work
s/mastiner/masinter/
lmasinter: i'm interested making sure the IETF specs are useful
chaals: good thing to do
IETF specs
chaals: where's the other mic?
lmasinter: there are 4 specs
... trying to describe what an IRI is
... there was a document for comparing IRIs
... a document for bidirectional IRIs
... combining LTR w/ RTL text
... and a document to update the URI scheme registration
... because people were confused about URI/IRI registration
... the IRI WG has been meeting for several years
... there'll be a meeting in Atlanta next week
... i'll be there
... i'm hoping if we'll get more test cases into the test suite
... we need to make sure the reality matches the right reality
... the specs are open
... there's a tracker with issues
... there's been about 60 issues
... there hasn't been much overlap between the people here and
there
... i haven't seen substantive work taking place here
... we did commit to doing work
... i've been doing work with SDQ
<hsivonen> I have been lead to believe only Opera implements
IDNA 2008. others implement 2003
lmasinter: on rfc 3987
<odinho_> [51]WHATWG URL spec
[51] http://url.spec.whatwg.org/
lmasinter: [52]http://tools.ietf.org/wg/iri/trac/report/1
[52] http://tools.ietf.org/wg/iri/trac/report/1
alex_russell: Alex Russell, Google
... who's signed up to implementing this?
lmasinter: the people who are there are those who have sent
email
chaals: while we have a URI spec in our WG
... i haven't seen anyone doing work on it
lmasinter: we put in 8 test cases, and all the browsers are
different about how they behave
timeless: just filing the bugs is a first step
lmasinter: [53]http://www.w3.org/wiki/UriTesting
...
[54]http://lists.w3.org/Archives/Public/uri/2012Oct/0007.html
... i've been trying to get Chris Weber to put his testcases
into a form where people can run them
[53] http://www.w3.org/wiki/UriTesting
[54] http://lists.w3.org/Archives/Public/uri/2012Oct/0007.html
Introductions continued
tobie: Tobie Langel, Facebook, everything
amirabella: XXX
alex_russell: Alex Russell, Google
dgrogan_cloud: David Grogan, Google, IndexedDB
mjs: Maciej, Apple, most things
<slightlyoff> timeless: I'm Alex Russell for the record
bradee-oh: Bradee, Google, ibid
<bradee-oh> s/Bradee/Brady/
<bradee-oh> s/Google/Apple/
spoussa: Sakario Poussa
Jungkee: Jungkee Song, Samsung
IndexedDB
sicking: we've gotten a bunch of feedback
... we've got a lot of feedback
... we need to integrate the feedback
... and then update the spec to use WebIDL
... we have good scripts from darobin to do that
... i've been slacking
... either i need help, or i need to make it happen
chaals: who's doing impl?
sicking: chrome and firefox are more or less fully spec
conformant
... ie10 is mostly there
... i don't know about opera
odinho_: pretty done
sicking: including blobs and array keypath?
odinho_: array keypath, yes
... blobs, some blobs
[ laughter ]
odinho_: it's being reviewed
... we need to figure out ordering
... exceptions
... we want to get it in pretty soonish
... blocked error
sicking: blocked vs. error
odinho_: having a blocked error vs. an onblocked event
... we wanted a simpler thing
... where the developer ...
sicking: we disagree
dgrogan_cloud: internally we talked about it
... we liked opera's proposal
... but since we already implemented
... we're ambivalent
sicking: there's the question of what microsoft wants
... there's also the question of exposing GC behavior
... the spec exposes some
... but if we do more, we may expose more GC
... the root cause is that there are GC effects
... i'm concerned about changing the spec given how implemented
it is
dgrogan_cloud: i don't know if we want to discuss this further
adrianba: we don't want to change the behavior we've
implemented
... we've shipped this
... we're building applications that depend on this
... the new version of exchange supports offline email using
indexeddb
chaals: so we have legacy implementation
... such is life
... is opera's request just make work?
sicking: so far, no one has opposed adding opera's requested
behavior in a new function
... i don't have a strong opinion
... but people will use the short named one with the bad
behavior
odinho_: if it has a longer name it will be less frequently
used
... i hope your exchange app doesn't need this
... if the browser asks the page to close the connection, it
should probably close the connection
... it's a corner case
we tried arguing this for a while before
scribe: it's quite late for us as well
... we implemented the other thing, it was extremely quick to
do
... the consensus is to keep the spec as is
... it's a corner case
... hopefully it won't hurt too much
... if it starts hurting, we'd fix it in bug fixing
... v2 features
... get database names
sicking: i think firefox is the only one w/o it
odinho_: we implemented it as we saw in the email
... since everyone is implementing this
... it'll be on the web platform in some form
sicking: we need to be able to figure out how to elevate new
features
... if someone wants to work on extended functions in a v2
... for get database names
... i'd request it's a safe thing
... if you try to open it right away
... you're guaranteed to have it there with the version number
you were told
odinho_: we did it super fast, so it probably doesn't do that
sicking: that was my requirement when we discussed it earlier
... ms came back and said it makes sense but didn't they could
do it in time
... it's implementable, but non-trivial to implement
adrianba: the other thing is that we've been close to a long
time
... but we should get this first spec finalized
sicking: i'm not interested in adding features for v1
odinho_: for some internal stuff, we need this
... since we need it, we're going to implement it
chaals: can we put it in an FPWD
sicking: i'm happy to put it in a draft if people are
chaals: sicking to write a v2 draft
odinho_: by next week
chaals: i heard by tomorrow
ArtB: v1 is in LC
... what's eliott's status?
adrianba: he's been pretty busy, but he's available
sicking: there's also exception ordering
... which could be a big chunk of work
ArtB: can i assume sicking and israel can help?
dgrogan_cloud: i don't think anyone from google has touched
editing
ArtB: we can editors
dgrogan_cloud: those editors have moved on to other projects
odinho_: the bug about undefined handling sounds
uncontroversiall
s/all/al/
scribe: treat undefined as missing
sicking: i think the behavior has been decided on
... webidl spec doesn't define the desired behavior
... treat-undefined-as-missing will be the default behavior
dgrogan_cloud: sounds like these are editorial things
chaals: there's issues
... but not complex/controversial
sicking: i think the only one is open()
... the exception issue is technical
... but it just needs to be defined
ArtB: can anyone from Apple/Safari comment?
bradee-oh: we have no comment
chaals: does anyone care about websql?
timeless: can you please bury it further than it's already
buried?
chaals: i don't know where's it's buried
... so good.
[ Break until 2:45pm ]
Push APIs
<npdoty> if you're trying to call in, please let us know if you
are hearing anything, and if not, ping me
bryan: we reached fpwd
<bryan>
[55]http://dvcs.w3.org/hg/push/raw-file/default/index.html
[55] http://dvcs.w3.org/hg/push/raw-file/default/index.html
bryan: i'd suggest we do a quick run through
... hopefully many people have taken a look at this
... we originally presented this in 2009
... last year we proposed doing this in the web-apps recharter
... in the interim we worked on this outside w3c
... this puts together things that are possible today using
different methods
... the focus of this api is on what happens between the
application and its runtime
... practical implementations take into account the platform in
which the application runs
... that includes browser/native os platforms
... or platforms from OMA/SMS/SIP
... whichever API is available/supported by the UA is supported
through the API
... when we put out our CfC
... we only got a question from sicking
... we can take comments, or walk through the spec...
chaals: can we skip through rapidly?
... who implements?
sicking: for mozilla
... unfortunately, it isn't an easy answer
... there are patches to do the proposed api for gecko
... for Firefox OS
... (B2G)
... it was very recently decided that it wouldn't ship in the
initial release of Firefox OS
... the api is implementable
... there's also an implementation of the server side
infrastructure
... the reason we aren't putting in v1 is the set of reasons
from my email
... we're not convinced it's the right solution
... we are going to start working on experimenting to see what
we think is the right solution
chaals: you're interested in Push
... you want to make something work
... if we had the same spec w/ different content?
sicking: we're very interested in push
... but we want a good design
/me sicking "implementation" -> "design" ?
s| /me sicking "implementation" -> "design" ?||
ed: we're working w/ mozilla
... and are very interested
BO_HU_CHINA_UNICOM: we're interested
... we won't be precisely implementing it
... but we're supportive of this unified api
... there's a question of whether there's a broker
... in /above the browser
... and accessible by web apps
chaals: you don't implement your own browser
BO_HU_CHINA_UNICOM: no, we don't
chaals: some operators say to certain browsers "you will do
this"
... and some produce enough content that browsers will do this
BO_HU_CHINA_UNICOM: we may have significant influence over
Chinese browsers
... if every web application builds on their own channel
... that's something to avoid
... it will have negative impact on devices and networks
pbakaus: we're interested in this
... we want to push messages to the client
... in our games
bryan: we believe there is a lot of interest in the concept
... it isn't possible today to do this outside an app by app
connection, or a shared worker
... how things are done is less of a concern than that they are
done
sicking: this draft is a lot closer to the right api
... than anything else that's been discussed in this space
... i'd love to hear from apple and google
... i'll note that a lot of companies have experience
... is apple interested in push for the web?
mjs: i think we'll need to wait for our legal department's
review of this FPWD
... from a technical review, i haven't read/considered this
spec
... your review has the concerns i'd want to express
... scalability and authentication are what i'd worry about
sicking: can we get the people w/ experience to comment?
mjs: probably not possible to get them to comment directly
... they aren't involved in standards
... but i can probably get them to look at it and forward
comments
... the way apple addressed this
... is that apple devices only trust apple servers
and apple forces app authors to create certificates which we
trust
scribe: i don't know of a way to avoid spam
sicking: i think this spec requires the device to trust the
push server
... but not the push server to trust the device
rafaelw: i think we're interested
<Zakim> timeless, you wanted to note that MS announced it had
for Skype in wp8
<ArtB> ACTION: rafael provide feedback on Push API [recorded in
[56]http://www.w3.org/2012/10/29-webapps-minutes.html#action09]
<trackbot> Created ACTION-672 - Provide feedback on Push API
[on Rafael Weinstein - due 2012-11-05].
adrianba_: so
... right now, Microsoft's experience / position is similar to
mjs's outline of Apple's
... notifications are built on top of windows live
notifications
... that messenger has provided
... we have a generic notification system
... operated by microsoft for WP
... it's tied in to the services provided by microsoft
chaals: does Opera have any position?
jgraham: i know nothing
ArtB: quick question, probably to bryan and ed
... in section 9
<efullea> it is efullea, not ed
ArtB: are there issues w/ w3 having normative references to OMA
/ similar specs?
bryan: i'm not aware of any
... establishing an api to connect to something supported by
the device
... shouldn't be an issue
chaals: tizen?
Wonsuk: Wonsuk, Samsung
... for Tizen
... i think it's a core feature for a lot of mobile apps
including Games/apps
... Samsung has its own service for this
chaals: so, everyone has a push system
... everyone who has one doesn't need a standard
... everyone who doesn't have a system want a standard
bryan: in 80% of phones worldwide, push is supported
<chaals> scribe: chaals
<npdoty> 30 minutes for coffee starting now, unless you want to
talk about Push API details, in which case stick around
timeless: "this" example is requesting permission. How does the
server side discover where it wants to talk to?
… does the platform get called to the URI?
… eg, zynga has an app on a phone, apple runs the network. I
open the phone, how does the zynga app register to the cloud,
so the zynga server knows where to send the push notification?
Bryan: There is a URL that the push service provides for the
app to register and invoke the operation.
… It's the service URL in the activate variable (we are in
example 1)
… it is passed up to the application, to kbow where to invoke
messages and what protocols are supported.
… There are a variety of ways it could be done - people have
worked on this for a dozen years or more.
Bryan. It is intended to describe the context of how push can
work
… show use cases like RTC, activity getting woken, multiple
instances of apps, etc.
… THings that folow from the use cases we proposed early on.
… Security/Privacy section was filled in on request - this is
fairly boilerplate text copied from DAP.
<timeless> timeless: fwiw,
"&serverProtocols="+mypush.serverProtocols; should probably
have an encode method, otherwise it's asking for pain :)
… referenced Jonas' comments
… So those are noted open questions for further discussion.
… Framework section gives a general explanation, but main bit
is between the app and the user agent. There are some artifacts
coming from the way permission is arranged.
… for registration. Challenge we have seen in current push
systems is developers lacking a way to globally implement a
push-based app.
… We're not presuming to establish one protocol for everyone,
but to enable the app to discover what services are available
in a given context.
… We have pretty much taken the suggestions from Jonas on
attributes for the interface. They facilitate some of the
questions about keys, etc. We need to get into detail about how
this addresses security, etc. Otherwise it is similar to server
sent events in design - type of events, ready state, etc.
… There is a section on service bindings. Based on work done
outside W3C and what might work well in W3C context. We left
stuff out to simplify, eg headers (compared to OMA)
… Same for SMS - no headers...
<ArtB> Scribe+ ArtB
Shadow DOM
<timeless> scribe: timeless
<ArtB> DG: [provides some history of the spec ...]
dglazkov: custom dom elements
... i started writing as a response to
... the needs from the mozilla folks
... who started implementing some of these things
... i felt i needed to start capturing requirements
... this spec is in the very early stages at this point
... for when people ask "how does this work"
... the shadow dom spec is in really good shape
... someone said "no plan survives contact with the enemy"
... in this case, the enemy is the users
... we discover that we haven't thought about this/we haven't
thought about that
... the other thing that can happen
... we tried to work w/ CSS WG a bit more
... there's a lot of concepts that bleed over from shadow dom
into css
... currently some things are hard coded in shadow dom
... but i want to redefine it in terms of displayed content
... which will enable the text to disappear
... i'm going to let rafaelw cover html templates
rafaelw: html templates is a collaboration between google and
microsoft
... tross
... the <template> element is from the web components effort
<morrita> s/displayed content/display: content/
rafaelw: web applications need a way to declare a fragment of
dom that isn't in use when the fragment loads
... but is used later
... this is important for declarative declaration of components
<adrianba>
[57]http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templ
ates/index.html
[57] http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html
rafaelw: for declaring shadow dom
... we're pretty close to FPWD
... a majority of the work is going into validating the parser
changes
... there was a discussion about contextless parsing, or
implied parsing
... there was a consensus about implied parsing
... the parser wouldn't have an explict context element
... it would choose it
... there seemed to be no dissent to doing this
... but there was an objection to an explicit api
(document.parse)
... the parser changes encapsulated changes are managed by the
<template> element
... changing the parser itself may be controversial
... i'm not sure if people have questions about the <template>
element
... there are two ideas
... one is accommodating this type of content
... the other is the concept of the content being inert
... the parser takes the content and makes it a document
fragment
... hsivonen here?
hsivonen: yes
rafaelw: i know you had concerns
hsivonen: this is such a radical thing to do
... it's radically unusual to do this sort of thing
... where the markup and data structure no longer have the
correspondence the DOM was designed to have
... DOM was designed to have an AST
... for XHTML
... we're breaking that
... not that i care about XHTML per se
mjs: how important is it to the goals of the <template> element
... is it to retain inline markup
... it seems like the template could have a src= attribute, or
a srcdoc= attribute
rafaelw: it's our opinion that it's worth doing
... we could imagine a future src= attribute
... srcdoc= is the more relevant proposal
... that was brought up on the mailing list including CDATA
... none of those proposals offer a good combination of
developer ergonomics
... recursively defined components
... a component that uses a templating mechanism
<hsivonen> I want the above-parser impl to be the same for HTML
and XHTML
rafaelw: it's my feeling that it's worth doing
Travis: standing in for tross
... i think our position is we don't care either way
<adrianba> s/tross/tross/
mjs: src[doc] solves the inert document question
... it's much easier to make a compatible polyfill model using
js with src[doc]
... you're creating a huge hazard for developers
... it's much easier to backfill this with js if you use
src[doc]
<annevk> s/src[doc]/srcdoc=""/
slightlyoff: it's possible to use display:none
... and have rules about not having side-effect code
... there's a thing TemplateXZ which does this
... we don't need to preclude one by agreeing that the other is
a good idea
s/+ alex_russell/+ alex_russell_(slightlyoff)/
hsivonen: for 2d / webgl, for perf reasons, people move to
webgl
... for polyfill it isn't clear that the benefits outweigh the
hacky thing
... people would rather use some new thing
... rather than something that works w/ ie10 w/in its support
peroid
s/oid/iod/
chaals: i get nervous about "new-that-breaks-backwards-compat"
slightlyoff: i'm not slightly sympathetic to that view
... it's microsoft's job to get their users off the old
browsers
... we have library authors who are adamant that this is what
they want
... document fragments don't do it
... EmberJS
s/EmberJS/Ember.js/
pbakaus: i tend to agree
... perf characteristics should also be considered
... if not making it backwards compat gives a big win
... it's worth it
chaals: yandex has no sympathy with your view that people
should force users to upgrade
... we ship content to most of russia
... and those users don't upgrade
... it costs us a boat-load when people change things
... if there's a way to avoid that
... and from a development perspective, it provides the
functionality
... then there's no question about which is right, and which is
insane
... we all want every browser user to upgrade
... but they don't
... it costs us boatloads to assume they do
mjs: developer ergonomics has been cited as an important reason
for this
... for components, it's assumed that components will be
reusable
... is it really assumed that they'll be included inline
... instead of at a shared place
... rafaelw said we will have to break compatibility
... we might as do it now
... what's that
dglazkov: i'll answer
<hsivonen> why aren't templates loaded via XHR?
dglazkov: the compat concern
... is really serious and valuable
... the whole issue comes down to
... compatibility
... and making sure you can provide this content to old
browsers as well
... and polyfill it
... you can develop a feature
... but this template feature
... srcdoc has bad regonomics
... how do we balance this
... mjs asked about reusable components
... but if for every definition of components, i need to fetch
some other file that defines this component, that's terrible
... sure you should be able to split them up
... but that shouldn't be the only way
... compatibility seems to be a bug-a-bear
... what is actually going to break
... and what can we say "this is ok"
... as someone who wrote a polyfill for templates in web
components
rafaelw: i didn't mean to imply that we need to break compat
dglazkov: i'm sorry i can't see your faces
... chaals you asked a philosophical question
[ scribe didn't minute it ]
<npdoty> rafaelw: I didn't have some specific
criterion/condition for why we would should break compatibility
at this point in time
dglazkov: if we're breaking something, how badly are we
breaking it
rafaelw: aside from static documents
... most apps hide templates with some hack
... comments, text fields, ...
... we're not going to make life any better
<hallvord> ... script tags ...
rafaelw: i don't think srcdoc is better than existing hacks
... using <script> is better than that
... pages keep content hidden, squirreled away somehow
... composing documents w/ innerHTML/script
... i don't think it should be controversial that there's an
established need for something better than we have now
... it's my opinion that we've settled on something
... it does need something
... parser changes
chaals: there's no disagreement that we need the functionality
... the question is how we get it
... is there anyone who says "we don't need <template>ing"
[ no one ]
hallvord: re: breaking back-compat
... what's the oldest computer in your circle of family/friends
... when we should develop the web
... we should accommodate them
slightlyoff: there are semantics we need to put into the
platform
... are there semantics we need to put into the browser
... we can auto update those browsers
morrita: why can't we extend
chaals: we all accept we need <template>ing
hsivonen: srcdoc= erognomics are bad
... and pages use <script>template-inline-here</script>
... we have XHR
... which works in all browsers
... why don't we specify templates be external resources loaded
via xhr
... considering we want script/css in external files
... for paving a cowpath, it seems people want to put this
inline
... why don't we want to use XHR for this?
rafaelw: that has a terrible perf profile
... production web sites go to great lengths not to break up
pages
<pbakaus> I agree with rafaelw
rafaelw: it's important to use inline declared content
... it's a non starter to say all content is remotely sourced
chaals: i buy the perf argument
... the dev ergonomics argument is harder
... the yandex BEM library
... (used by our biggest competitor as well)
... sources things externally
... if we started out by bringing templates in w/ srcdoc
... and we then said "it'd be really cool if we could drop this
in line"
... could we get consensus sooner
<Zakim> mjs, you wanted to ask, if you can polyfill fine now,
why do we need a new feature for inert dom?
mjs: that needs to be a huge win given the acknowledged high
cost
... what are the downsides of <Script type=non-standard>
... we could make <script type=standard>
<Zakim> timeless, you wanted to ask about HTTP2
<chaals> timeless: Developers void splitting content to save
load time. If we had HTTP2 that solved that issue, would it be
better.
pbakaus: we can't live with a solution that requires XHR
... the games we're building require complete inlining
... to the extent of a single request
... on mobile
sicking: it seems provable that people can use external
... but they use inline hacks
<darobin> +1 to jonas
sicking: we might as well not do anything at all if that's the
solution we're advocating
jaubourg: it seems like a tooling issue
... consider <script>
... you have tools to handle dependencies
... in development you can external resources
... in production you inline scripts to a single file
... if you had a tool that could do the concatentation
... if you had a script to fetch external/do inline
rafaelw: if we had HTTP2, would that address the external
resource latency issue
... i'm not sure the status of HTTP2
... if external latency wasn't a problem, then would it not be
a problem
mjs: what's the problem w/ <script type=random-mime-type>
rafaelw: script tokenization stops when it sees </script>
... which means you can't have recursive templates
... to embed a <script> in your template
... they break the script into two tokens
... hitting </script> in the script token ends the script token
mjs: with some small amount of escaping, you could address that
timeless: we have today <\/script>
rafaelw: you're asking if we can stick with what we have
... slightlyoff mentioned it's painful
mjs: is the pain-point lack of built in
<slightlyoff> ...and the frameworks vendors agree
mjs: or is it the escaping
... i believe that having to roll their own templating
... reguardless of the syntax
<chaals> ?
mjs: but if we had a defined script type
... would just the need to escape </script> be such a pain
point?
... i'm skeptical
rafaelw: my sense is it's pretty painful
... i'd let yehuda katz and mishko (angular) speak for
themselves
<Zakim> timeless, you wanted to ask about <script> v. <script
src>
<slightlyoff> Lachy: wait, what?
<slightlyoff> are you actually kidding?
<slightlyoff> I think you're trolling
timeless: <script> was inline first
<Lachy> slightlyoff, no. It's one little extra character that
authors would have to type. How is it hard? It's already needed
when doing things like document.write("<script …><\/script>");
timeless: and <script src> was added later
... but i think that 80-95% is now <script src>
<MikeSmith> s/mishko/Miško Hevery/
dglazkov: pending a polyfill for feature
<mjs> SimonPieters: you could probably design it so only a
single level of escaping is needed regardless of nesting
<annevk> <\/script> is shorter than </template> :p
dglazkov: angular/Ember.js
... they have a specific UC
<slightlyoff> timeless: I think you're also wrong about this.
Most script tags are ads, and they tend to marry
inline/out-of-band <script> elements = )
dglazkov: it's hard to do one that's universal
<ericu> artb I'm about to call in.
dglazkov: polyfills are never 100% faithful
<mjs> SimonPieters: the escaping is only needed to be
compatible with legacy <script> parsing, not fundamentally for
a hypothetical <script type=template>
dglazkov: we have views of breaking compat as the general
... i know rafaelw studied this and there's very little that
actually changes
... most still works
<ericu> artb, I can hear you now.
<annevk> mjs: change end tag parsing based on an attribute
value? o_O
dglazkov: throw someone if they suggest XHR agian
s/agian/again/
scribe: we could solve everything with escaping
<mjs> annevk: not sure how that follows?
scribe: but people don't always remember to escape
<pbakaus> +1
<aklein> mjs: I think annevk is asking how the parser finds the
end-tag in <script type=template> parsing
<mjs> annevk: <script type=template><script
type=template><script
type=template><\/script><\/script></script>
chaals: calling you on this, it's a sales pitch
<annevk> mjs: right that uses the escaping
<mjs> annevk: nothing about that needs to change existing
parsing based on an attribute
hsivonen: people who write libraries
<mjs> annevk: yeah but you don't need to double-escape the
innermost one
<mjs> annevk: that
hsivonen: if this feature was available
<annevk> mjs: oh
<mjs> that is all I meant
hsivonen: would they stop using <script>?
<annevk> k
hsivonen: i have the bad feeling that balancing the new feature
/ availability
... the compat tends to win over inconvenience
... do we believe that yehuda/ Miško would break compat
sicking: re: HTTP2, it only solves additional overhead
... for requests
<mjs> sicking, it can solve extra round trip latency b/c it
lets the server push resources it thinks are needed
<slightlyoff> hsivonen: this is absolutely the wrong question.
Holding a feature that can help the future out to the idea that
some vendor will adopt it *immediately* is standards judo of
the worst sort.
pbakaus: almost everything can be solved in terms of tooling
<morrita> maybe <template> could be just an alias of <script>
to avoid escaping?
pbakaus: building tools is extremely hard
... we did it
<slightlyoff> making the world safe for new features need not
be held up by current practice
pbakaus: but not everyone can
... we want standards everyone can use
chaals: spend some time tonight w/ beer to talk about this w/
someone who doesn't agree
... the market will determine what's used
<jaubourg> pbakaus: I was talking about tooling to transform
tags that link to external resources into a tag with content
inline. I know <template> is needed. I was just telling that
people are inlining right now because tooling is hard, liike
you said
<sicking> mjs: the server needs to know about it to solve the
roundtrip issue. I think it's also the case that the way it
works is that the server can "pre recommend" that the client
downloads a resource, but the client stil has to request it.
But I'm not sure that that works
timeless: i'm pretty sure that the server can actually send the
resource too instead of just recommending it
File * APIs
ericu: about the file system api
<mjs> sicking, I suppose it could change but I don't believe
that's how it works in the current SPDY protocol
[58]http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-dr
aft3#TOC-3.3-Server-Push-Transactions
[58] http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3#TOC-3.3-Server-Push-Transactions
ericu: there's been discussion about note tracking it
... two questions
... is there a quorum of browser vendors likely to implement at
all
... if not, then note track
... if so, we should keep talking
... if there's interest
<hallvord> slightlyoff: more features = more complexity, more
features = less back-compat - this is always a tradeoff. So we
need to look carefully at how much value new features provide.
ericu: should we move forward, throw away + start over w/
sicking / mjs's proposals
... or try to evolve current work to something near proposal
<slightlyoff> hallvord: I think that's just absolutely the
wrong perspective: folks are building this stuff the hard,
slow, expensive way
adrianba: we'll never say never
... but right now we don't see the file system api as a high
priority
... we focused on indexeddb
... making sure you can store blob data there
<hsivonen> sicking: I believe SPDY allows a response before
request, so the server could send *everything* over when the
initial request has been made
adrianba: right now, making sure that's an adequate solution
timeless: what hsivonen said
ericu: could a file system api provide photos directory access?
adrianba: not from the browser
chaals: anyone want to speak in favor of it?
bryan: this is the file system directory apis?
<sicking> hsivonen: mjs: timeless: Ok, appears I was wrong and
"full" server push is supported.
ericu: right, directory api + writer
bryan: writer w/o reading is useless
... browsers will need to be able to store hundreds of files
and gb's of data
<hallvord> slightlyoff: you're saying we should never be asking
"how hard now? / how much easier tomorrow?" for a new feature?
You see no trade-offs to be made at all? ;-)
sicking: simple answer is indexeddb supports any amount/number
of files
<adrianba> s/not from the browser/not from the browser, at
least in the short term/
sicking: any file stored in indexeddb in firefox today
... is stored as an actual file
<slightlyoff> hallvord: trying to engagine you in PM but you're
not responding there. Are you auth'd?
sicking: we haven't optimized for all cases yet, but that's
something we'll work on
... i don't believe it's possible to evolve the current file
system proposal from google into something like mjs/my proposal
... i like mjs's proposal
... it's possible to evolve that proposal
... mozilla's proposal supports doing small writes to files
... mjs asked if there's UCs for that
... we should provide use cases for that, i believe they exist
... there were other proposals which allowed incremental
writing
... mozilla's proposal has atomic writing
... unix's doesn't have this
... ms got this right
... we don't have good locking mechanisms on the web
... i'd like something with the same capabilities as mozilla's
... but not tied to that api
mjs: my proposal supports incremental writing
... but it could be simplified if it wasn't needed
... interest in file system apis in general
... my own opinion
... not necessarily apple's
... we've added too damn many storage apis to the web platform
... i'd much prefer to see
... if there's a short list of features not available to
indexeddb
... let's add them there
... if there's a reason that's impossible
... let's try to create something minimal
s/../.../
scribe: it's much easier to take something too simple and add
... than to subtract
<SimonPieters> I agree with mjs, FTR
pbakaus: we're fine w/ either approach
<chaals> ak pb
pbakaus: i can't w/ indexedb
... is local file protocol handlers
... to be able to use a file in <script src>/<style src>
ericu: i think most of what i had in mind is covered
... you can store large files in indexeddb
... chrome doesn't have blobs yet, but we will
... large mutable data in indexeddb isn't appropriate
... transactions on gb's of data is painful
... sicking has a proposal
... i don't see an efficient way to deal w/ large mutable blobs
in indexeddb
... a file system api is the only proposal that addresses that
sicking: indexeddb doesn't support large mutable files
... i have a proposal for that -- not super clean, but it
definitely works
... the other is file system protocol handler
... i haven't thought of a clean way to do it
... but it's technically possible
... something we can explore
... if we add this to indexeddb, it won't be super clean
... but it's something we can explore
mjs: externally referenceable blobs as a feature
... then we should put it into indexeddb
<bryan> If we have the ability to layer a virtual filesystem
capability on IndexedDB via JavaScript, at least for
non-mutable large blobs, at least that provides a means to
develop implementations for the media gallery and offline
content storage use cases, and would be a step in the right
direction.
mjs: and large mutable blobs
... likewise
chaals: how many file system hands in webapps?
... darobin, pbakaus, jaubourg, spoussa
... maybe half a dozen people here
... eric, if you're prepared to keep editing, i'm not prepared
to throw you on note
<slightlyoff> OH HAI arunranga
chaals: who's interested in the current file spec?
... ericu, do you want to vote?
<odinho_> s/OH HAI arunranga//
chaals: i'd like to work on sicking 's suggestions (locking),
and possibly strip it down
<bryan> I would still prefer the File* APIs remain REC track
until the IndexedDB alternative is proven feasible through
testing of available implementations.
s/chaals/ericu/
pbakaus: i'd like to say...
... indexeddb or filesystem
... the abstract concept of working with files
... is good
... if we can do that in indexeddb as well, then i'm totally
happy
<ericu> timeless, I talked about stripping down the current API
towards the Mozilla proposal, not strip down Mozilla's.
chaals: it sounds like we should suggest that you make a file
system spec
... should we drop the work item, and just do something on top
of indexeddb
timeless: it seems like the simplest thing is a spec for making
indexeddb referencable objects from uri's for use in
script-src/style-src
sicking: it seems like the support can't be lower
... i'm not sure about the official cut off is
chaals: i'm not reading any support for the spec as is
... i'm not seeing any support for the spec as is
pbakaus: many people agree on the feature spec
... is it one spec that covers everything
... that covers db and stuff
... or multiple specs
chaals: i don't see the consensus to just stop work on that
... that'd be a thing via a CfC
mjs: one option is to tombstone the current draft
... and then give people the opportunity to offer a counter
proposal
... which would probably be a delete and replace
... i'm not sure if ericu is willing to do that
ericu: obviously there's no support for the current draft
... i'm interested in iterating the current draft to what
sicking is suggesting
... sounds like sicking isn't expecting me to iterate far
enough close to his draft
sicking: it seems implausible that it can be iterated
... it seems better with a replace than a modify
bryan: with indexeddb as i could with filesystem
... would apps with different origins have access to the same
indexeddb?
chaals: file systems can be shared
... maybe we should keep the idea alive?
jgraham: my view is similar to mjs's view
... we've invented a lot of storage apis
... so far they've been really bad
... let's work on the one we have that we haven't proven to be
really bad
... before we spec a new one
... let's let authors build on top of indexeddb
... and let them build interfaces
... and see if we can steal their api/concepts
chaals: you're too late
... we have started specing file system apis
... we even specified them in the 70s
paulc: some of us are older than...
[ laughter ]
chaals: adding 47 apis just because we can
timeless: that's what sysapps is for
jgraham: it's about creating another legacy which is bad
... we've had 3 different proposals
... which have had varying levels of support
... unless there's something really compelling that we had to
do yesterday
... i don't think there is
chaals: js libraries don't have access to the file system
jgraham: but they will make apis on top of indexeddb to pretend
to be a file
timeless: i suspect we could see apps written using DnD support
+ indexeddb to emulate the file system
<bryan> does someone have links to any javascript-based
indexedDB filesystems that anyone is currently playing with? If
it's a good and feasible idea, then surely someone is trying to
do it.
pbakaus: let's keep the feature set of the current file system
slightlyoff: we should stop iterating
... because we got it wrong last time
<bryan> i can't find anything on the web of a similar nature
using indexeddb.
slightlyoff: seems like a bad argument
jgraham: that's not the argument i was making
... once we do something, it's fixed in stone
... it's very hard to change
... when a js library makes something
... it can make it look like a file
... and design things
<slightlyoff> timeless: that's not what I said
<slightlyoff> I said that we *shouldn't* stop iterating
<slightlyoff> also, I object that there is equivalence between
what JS libraries will do with an API vs. exposing a new
fundamental capability
chaals: how many people think we should keep working on the
current file system api?
<slightlyoff> they're different orders or magnitude in change
[ 12 ]
chaals: how many people think we should ask ericu to stop
working, and then wait for a new editor?
[ around 12 ]
chaals: ericu, you're welcome to keep working on this
... if we get someone to edit another proposal
... put the two up
... and ask the group to choose
... is that an outcome people would be happy with?
[ 15 ]
chaals: the number of people in the room change faster than the
number of questions
shepazu: seems clear we want some sort of file system api
timeless: you could create a competing one for yourself
ArtB: arunranga is on the call
File Reader API
chaals: darobin was going to ship this in 2006
arunranga: fileapi is done
... but there's a question of auto-revoke
... auto-revoke of Blob URIs is a question
... there's a question where to put auto-revoke of Blob URIs
with the HTML5 spec
... microtask checkpoints
... i think we're around the corner from it
... i think discussing it on the list makes sense
chaals: so there's one outstanding issue
arunranga: ms2ger wrote a nice test suite
ArtB: anyone want to add something to the test suite?
chaals: please?
... krisk just volunteered to add to the test suite
adrianba: i wanted to mention one other issue
... events that fire for file reader
... file reader is designed to be reusable
... you can call read() on an instance
... and then call again() on that instance
... assuming one isn't pending
... there's discussion on the list about which events to fire
<jgraham> We might have more tests
adrianba: if you call read() during load/XXZ
... there's a question of what to do
... our proposal is to not fire load-end for the first() read
if there's a second read() outstanding
arunranga: the last i remember of that discussion
... we set it up so you couldn't call read() multiple times
... it would throw an exception
... if that isn't resolved adequately...
adrianba: i thought that resolution was for if you tried to
call read() while there's a second read()
timeless: is this read() triggers load... loadend, and there's
a chance of calling read() after the last load fired but before
loadend ?
pbakaus: maybe we could discuss archive reader tomorrow?
chaals: toss it on the agenda wiki
... thank you very much
... thanks to timeless for scribing
[ applause ]
<ericu> pbakaus I won't be on tomorrow, but any reason you
can't do that in javascript?
chaals: we resume tomorrow @ 9 am
<pbakaus> uh – I think it's simply not fast
[ adjourned ]
<ericu> pbakaus try it and see if it's too slow, use that as a
proof of utility?
trackbot end meeting
<pbakaus> ericu: to elaborate, a JS based solution is probably
too slow for general purpose
s/trackbot end meeting//
trackbot, end meeting
Summary of Action Items
[NEW] ACTION: barstow follow up with Kinuko Yasuda on status
and plan for Quota Management API [recorded in
[59]http://www.w3.org/2012/10/29-webapps-minutes.html#action04]
[NEW] ACTION: barstow start a Call for Review for Web IDL test
plan on public-script-coord [recorded in
[60]http://www.w3.org/2012/10/29-webapps-minutes.html#action07]
[NEW] ACTION: barstow work with Jong-Heun Lee to start a RfR
Web Storage test suite [recorded in
[61]http://www.w3.org/2012/10/29-webapps-minutes.html#action05]
[NEW] ACTION: barstow work with Opera Websocket tester(s) on a
Request for Review of their web socket tests [recorded in
[62]http://www.w3.org/2012/10/29-webapps-minutes.html#action08]
[NEW] ACTION: barstow work with PLH on an announcement seeking
IRC fragments [recorded in
[63]http://www.w3.org/2012/10/29-webapps-minutes.html#action06]
[NEW] ACTION: Barstow work with Travis on a CfC for DOM3 Events
Candidate [recorded in
[64]http://www.w3.org/2012/10/29-webapps-minutes.html#action03]
[NEW] ACTION: Charles start the process to move Widget Updates
to Candidate Recommendation [recorded in
[65]http://www.w3.org/2012/10/29-webapps-minutes.html#action01]
[NEW] ACTION: rafael provide feedback on Push API [recorded in
[66]http://www.w3.org/2012/10/29-webapps-minutes.html#action09]
[NEW] ACTION: Travis create an ED of DOM4 Events [recorded in
[67]http://www.w3.org/2012/10/29-webapps-minutes.html#action02]
[End of minutes]
Received on Monday, 29 October 2012 16:56:07 UTC