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

Draft Minutes: 29 October 2012

From: Arthur Barstow <art.barstow@nokia.com>
Date: Mon, 29 Oct 2012 17:55:29 +0100
Message-ID: <508EB501.3000504@nokia.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:55 GMT