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

Re: Minutes from WebApps' 2 November 2010 meeting

From: Eric Uhrhane <ericu@google.com>
Date: Thu, 4 Nov 2010 17:34:18 -0700
Message-ID: <AANLkTikNWsU7eB3jm-vuQyx-fEP9OcWTMthj4=yoUYBQ@mail.gmail.com>
To: Arthur Barstow <art.barstow@nokia.com>
Cc: public-webapps <public-webapps@w3.org>
On Wed, Nov 3, 2010 at 12:57 AM, Arthur Barstow <art.barstow@nokia.com> wrote:
> The draft minutes from WebApps' November 2 meeting in Lyon are available at
> the following and copied below:
>
> http://www.w3.org/2010/11/02-webapps-minutes.html
>
> WG Members - if you have any comments, corrections, etc., please send them
> to the public-webapps mail list before November 10; otherwise these minutes
> will be considered Approved.
>
> -Art Barstow
>
>   [1]W3C
>
>      [1] http://www.w3.org/
>
>                               - DRAFT -
>
>                          WebApps F2F Meeting
>
> 02 Nov 2010
>
>   See also: [2]IRC log
>
>      [2] http://www.w3.org/2010/11/02-webapps-irc
>
> Attendees
>
>   Present
>          ArtB, DougS, MikeSmith, Geoffrey, SamW, Maciej, DaveR, Olli,
>          Adrian, EliotG, LaszloG, YaelA, AnssiK_SureshC, Dom, Johnson,
>          AnneVK, KlausB, Wonsuk_Lee, RichardT, BryanS, KaiH,
>          Bryan_Sullivan, Jonas, Pablo, Jeremy, Andrei, BoChen,
>          DavidRogers, EricU, AdamB, Anssi_Kostiainen
>
>   Regrets
>   Chair
>          ArtB
>
>   Scribe
>          Mike_Smith, MikeSmith, anne, jorlow
>
> Contents
>
>     * [3]Topics
>         1. [4]DOM3 Events
>         2. [5]possible plans for console object spec/WG
>         3. [6]Audio XG
>         4. [7]XHR Testing
>         5. [8]XHR2 responseArrayBuffer
>         6. [9]Web DOM Core
>         7. [10]IndexedDB
>         8. [11]Keys
>         9. [12]internationalization
>        10. [13]Dynamic transactons:
>        11. [14]synchronous API
>        12. [15]Bugzilla
>        13. [16]quotas
>        14. [17]blobs
>        15. [18]Indexed DB Last Call
>        16. [19]File API
>        17. [20]FileSaver
>     * [21]Summary of Action Items
>     _________________________________________________________
>
>   <Barstow>  ScribeNick: MikeSmith
>
>   <Barstow>  Scribe: Mike_Smith
>
>   <Barstow>  Date: 2 November 2010
>
>   <scribe>  scribe: MikeSmith
>
> DOM3 Events
>
>   <shepazu>  [22]http://www.w3.org/2008/webapps/track/products/2
>
>     [22] http://www.w3.org/2008/webapps/track/products/2
>
>   <shepazu>
>   [23]http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Event
>   s.html
>
>     [23]
> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html
>
>   shepazu: first is to our tracker page
>
>   … does not have every issue
>
>   … because CLOSED issues don't show up
>
>   … this reprepsents most of our LC technical comment
>
>   … we figured we might have to go through LC gain
>
>   … we will be adding the locale string
>
>   … as we discussed yesterday
>
>   … we will be making small changes
>
>   … improving wording
>
>   … editorial explanations
>
>   … going to LC again in Jan
>
>   … this time "for reals"
>
>   <scribe>  … pending any upheavals
>
>   … doesn't specifcy evvery possible thing
>
>   … we had a comment from Garrett Smith
>
>   … also from Ample SDK
>
>   anne: Sergei Ilinsky
>
>   shepazu: wansts to modularize
>
>   … and Anne wants to modularize more too
>
>   shepazu: introduces all the things that were in DOM2 events
>
>   … plues text input, keyboard input, one mutation event
>
>   … though we have deprecated all the other mutation events
>
>   shepazu: I think we are more or less fr
>
>   … feature complete
>
>   anne: I'm the editor of DOM Core
>
>   … I think it make sense for DOM Core to define mutation events
>
>   anne: simiilar to how we define Form events inside the Forms spec
>
>   shepazu: we removed some Form-related events and those were moved to
>   the Forms spec
>
>   mjs: How about making mutation events die in a fire?
>   ... I agree if they have really tight coupling to DOM behavior, it
>   makes sense to have them in the same place
>
>   … but tehre are some cases that don't require tight coupling at all
>
>   weinig: some of our chagnes are pending that they don7t break major
>   editing sites
>
>   … or goal is to turn it on and see what sites break
>
>   anne:
>
>   smaug_: I don't understand why were are moving mutation events
>
>   … I thought everybody just wanted them removed
>
>   mjs: I thikn the DOM events mechanism really has become part of the
>   core
>
>   smaug_: yeah, but some specs may refere DOM events, but don't need
>   to use DOM core
>
>   mjs: there is almost no way to use DOM events without also using DOM
>   core
>
>   anne: what is an example where it's that case that something relies
>   on DOM events but not DOM core
>
>   smaug_: some specs just extend [by adding new events and so don't
>   need to reference DOM core]
>
>   shepazu: anne, please explain what you want to move, specifically
>
>   <mjs>  [24]http://www.w3.org/TR/DOM-Level-3-Events/#event-interfaces
>
>     [24] http://www.w3.org/TR/DOM-Level-3-Events/#event-interfaces
>
>   anne: there is a part call "Basic Event Interfaces"
>
>   … it would make sense to split that part out
>
>   shepazu: that is the core of DOM3 Events…
>
>   anne: in addition to that, I think the mutation events should move
>   too
>
>   mjs: smaug, I think your dependency argument doesn't work [because
>   the dependencies are complex]
>
>   anne: this is implementable in Java
>
>   <mjs>  what I said about dependencies is that DOM3 Events has a
>   normative dependency on DOM 3 Core
>
>   <mjs>  so there's no such thing as depending on DOM Events without
>   depending on DOM Core
>
>   Art: anybody else have comments?
>
>   adrianba: I don't have a strong opinion about where we go in the
>   long term
>
>   … there is plenty of time to talk about it
>
>   … right now there is an Event spec
>
>   … which is what we are targeting in IE9
>
>   … it seems like the wrong time now to start cutting up the problem
>   space in a different way
>
>   … let's move the spec forward as it is
>
>   adrianba: we are chartered to work in a new async spec for
>   [something like mutation events]
>   ... stabilizing what we how now and moving forward seems like the
>   right thing
>
>   mjs: my preference would be to move forward but plan [to move things
>   to DOM Core later]
>
>   smaug_: I agree
>
>   … let's get DOM3 Events done now
>
>   … DOM Core will take years
>
>   adrianba: we have implemented some of the mutatation events
>
>   … we all understand the problems with mutation events
>
>   anne: I am afraid we are getting stuck with mutation events
>
>   adrianba: we are kind of stuck with them anyway
>
>   shepazu: if you are going to do part of it, it should all be in one
>   spec
>
>   anne: what do you mean by all?
>   ... I don't think mouse events belongs together with it
>
>   shepazu: I would agree that we should move DOM3 Events forward as it
>   stands
>
>   anne: I don't think labeling them as deprecated helps us all that
>   much
>
>   mjs: if the number of implementations is increasing, then [clearly
>   it's not helping]
>
>   anne: making them async would be a big start
>
>   smaug_: we don't know that that will work
>   ... tehre are some other approaches that are not event-based
>   ... it is possible to remove some features from the platform
>
>   … it has been done
>
>   shepazu: deprecation is a warning to authors
>   ... it's not helpful to remove them from the spec at this point
>
>   weinig: if they were removed from DOM3 Events, would MSFT consider
>   not adding them in IE9
>
>   [adrian shakes his head]
>
>   shepazu: they are only supporting some of them
>
>   adrianba: we are supporting them for interoperability reasons
>
>   shepazu: they are in the spec because implementors asked for them to
>   be in the spec
>
>   art: I noticed big list of issues
>
>   shepazu: a bunch of them are from David Flanagan
>
>   [book author
>
>   shepazu: Oli, Travis, Jacob Rossi, myself discussed them
>
>   … we have agreed already to accept most of the comments
>
>   … and have heard no objections from the list
>
>   shepazu: event.timestamp is one that we have still be discussing
>
>   art: can you do all 50 0f these by the end of the year?
>
>   shepazu: we can round-trip on these by end of January
>   ... if nobody has more comments, let's move on
>
>   art: we don't have our next topic scheduled until 11am
>
> possible plans for console object spec/WG
>
>   shepazu: a lot of people have said why don't specify the console
>   object
>
>   weinig: we just copied the console api into Webkit
>
>   mjs: there are a few things around console that are
>   Web-compatibility issues
>   ... having to do with devs using console calls into their scripts
>   even after they have done debugging
>
>   weinig: there are a couple problems
>   ... we don't think operations on the console should be visible to
>   Web pages
>
>   … we made some mistakes around that
>
>   mjs: the fact that console.log exists and doesn't have potentially
>
>   ->  [25]http://getfirebug.com/wiki/index.php/Console_API Console API
>
>     [25] http://getfirebug.com/wiki/index.php/Console_API
>
>   adrianba: we having implemented the console in IE8-IE9
>   ... there is a session tomorrow to discuss a new community-driven
>   spec-dev approah
>
>   … this might be a good case to use as a pilot
>
>   … for that approach
>
> Audio XG
>
>   shepazu: about 6 months ago, we got in contact with some devs who
>   were working on an api from programatically writing and reading
>   audio streams
>
>   … and we started in Incubator Group
>
>   … XG
>
>   <Barstow>  Audio XG Charter:
>   [26]http://www.w3.org/2010/04/audio/audio-incubator-charter.html
>
>     [26] http://www.w3.org/2010/04/audio/audio-incubator-charter.html
>
>   shepazu: and right now, Mozilla has a related API they have have
>   developed
>
>   … and Googl Chrome team has a related API as well
>
>   shepazu: and we have decided to start a new WG
>
>   <Barstow>  Audio XG's mail list archive:
>   [27]http://lists.w3.org/Archives/Public/public-xg-audio/2010Oct/
>
>     [27] http://lists.w3.org/Archives/Public/public-xg-audio/2010Oct/
>
>   <Barstow>  Mike: Chrome team is working on this API
>
>   <Barstow>  ... think we want broader participation
>
>   shepazu: we would probably start the WG by February or so
>
>   Barstow: we will be back at 11am with anne at the podium
>   ... XHR1 test suite, and XHR1 issues
>
>   [we take a 1 hour break:
>
>   <anne>  [28]http://bitbucket.org/ms2ger/domparser
>
>     [28] http://bitbucket.org/ms2ger/domparser
>
>   <ArtB>  ACTION: barstow ask Doug for a pointer to Google's "Before
>   Input Proposal" [recorded in
>   [29]http://www.w3.org/2010/11/02-webapps-minutes.html#action01]
>
>   <trackbot>  Created ACTION-608 - Ask Doug for a pointer to Google's
>   "Before Input Proposal" [on Arthur Barstow - due 2010-11-09].
>
>   <ArtB>  issue-119?
>
>   <trackbot>  ISSUE-119 -- Consider adding input/keyboard locale to
>   text and keyboard events -- open
>
>   <trackbot>  [30]http://www.w3.org/2008/webapps/track/issues/119
>
>     [30] http://www.w3.org/2008/webapps/track/issues/119
>
>   <Barstow>  ScribeNick: timeless_mbp
>
>   <timeless>  ScribeNick: timeless
>
> XHR Testing
>
>   Scribe+ timeless
>
>   ArtB: Anne will be talking about XHR Level 1 Test Suite
>
>   <anne>  [31]http://tc.labs.opera.com/apis/XMLHttpRequest/ and
>   [32]http://tc.labs.opera.com/svn/apis/XMLHttpRequest/
>
>     [31] http://tc.labs.opera.com/apis/XMLHttpRequest/
>     [32] http://tc.labs.opera.com/svn/apis/XMLHttpRequest/
>
>   … and Level 1 issues
>
>   anne: XHR Level 1 went to CR
>
>   … which means it's awaiting implementations
>
>   … of course XHR has been implemented long ago already
>
>   … there is a test suite which has been announced on the list
>
>   … but there has been little response
>
>   … Since people are here now, I guess I can ask people directly
>
>   sicking: I haven't looked at the testsuite yet, but is it fully
>   automated?
>
>   anne: you need a test harness, but it is automatic loaded a test
>   says PASS/FAIL
>
>   sicking: i think one of our desires is that things be as automated
>   as possible
>
>   anne: I agree
>
>   <anne>
>   [33]http://tc.labs.opera.com/apis/XMLHttpRequest/abort-during-done.h
>   tm
>
>     [33] http://tc.labs.opera.com/apis/XMLHttpRequest/abort-during-done.htm
>
>   … ? there is a testharness that it's written for which is used for
>   other testsuites from this group
>
>   [ anne describes how individual tests are structured ]
>
>   adrianba: how much has the test suite changed recently?
>
>   anne: the framework changed to make it the same as the HTML WG
>
>   … quite a few changed because a number weren't matching the spec
>   anymore
>
>   … the old testsuite was quite outdated
>
>   … some tests have been removed
>
>   … the number of tests has gone down. because some test assertions
>   were combined into single test
>
>   dom: did you follow any specific method to ensure every feature has
>   been tested?
>
>   anne: um, no
>
>   … i tried reading carefully to ensure everything is covered
>
>   artb: do you think anything is missing?
>
>   anne: there's an open item in the issue database about credentials
>   in urls
>
>   … the tests around that and authentication are not done yet
>
>   <dom>  (should known bugs in the test suite be documented somewhere?)
>
>   <timeless_mbp>  bryan: did you want to test posts?
>
>   <timeless_mbp>  … for redirects (?)
>
>   <timeless_mbp>  anne: i didn't want to because HTTP Biz is still
>   undecided on some of this
>
>   <timeless_mbp>  … 301/302/307 ...
>
>   <timeless_mbp>  sicking: another thing is that Mozilla + Opera
>   include dialogs on 307
>
>   <timeless_mbp>  … it's sort of a requirement in the HTTP spec
>
>   <timeless_mbp>  … but they don't have it for direct address
>
>   <timeless_mbp>  … they're ratholes, so not tested yet, once they're
>   resolved they'll be tested
>
>   <timeless_mbp>  anne: the only accessible methods are GET and POST
>
>   <timeless_mbp>  sam: didn't hixie add DELETE?
>
>   <timeless_mbp>  anne: we got him to remove it
>
>   <timeless_mbp>  anne: Trailers aren't tested yet, because i didn't
>   know about them or how to test them
>
>   <timeless_mbp>  sicking: so do we have to test them?
>
>   <timeless_mbp>  anne: i might be able to test things w/ nph-
>
>   <timeless_mbp>  … but i'm not sure what to expect
>
>   <timeless_mbp>  sicking: trailers are after the response body
>
>   <timeless_mbp>  anne: so i guess the text that talks about the
>   response body would have to talk about changing the state
>
>   <timeless_mbp>  … as far as i'm concerned, we don't need to support
>   it
>
>   <timeless_mbp>  … for readyState changes
>
>   <timeless_mbp>  … but do you go to the done state
>
>   <timeless_mbp>  sam: you said the php scripts are available in an svn
>   server?
>
>   <timeless_mbp>  anne: yeah, it was the second link i posted
>
>   <dom>
>   [34]http://tc.labs.opera.com/svn/apis/XMLHttpRequest/resources/
>
>     [34] http://tc.labs.opera.com/svn/apis/XMLHttpRequest/resources/
>
>   <timeless_mbp>  artb: i assume the action then is for everyone to
>   help this spec reach the exit criteria
>
>   <timeless_mbp>  … is to review the tests
>
>   <timeless_mbp>  anne: i assume there are some spec/test items which
>   need fixing
>
>   <timeless_mbp>  … there's one other small test which might need
>   fixing
>
>   <timeless_mbp>  … Björn Herman
>
>   <timeless_mbp>  … pointed out byte order mark character
>
>   <shepazu>  s/Byorn Herman/Björn Höhrmann/
>
>   <timeless_mbp>  artb: we had set expectations that we wouldn't exit
>   CR before Feb 2011
>
>   <timeless_mbp>  sicking: which is two conforming implementations?
>
>   <timeless_mbp>  anne: I don't think that's likely to happen
>
>   <timeless_mbp>  … I would encourage people to review the editor's
>   draft instead of this
>
>   <timeless_mbp>  … because there have been some changes to make this
>   closer to XHR2
>
>   <timeless_mbp>  … removing some throw conditions to enable CORS
>
>   <timeless_mbp>  … those have been reflected in the testsuite already
>
>   <timeless_mbp>  … i try to keep the testsuite and the draft in sync
>
>   <timeless_mbp>  … that also means that if you implement to the
>   testsuite, there shouldn't be any conflicts with XHR2
>
>   <timeless_mbp>  … if there are, that would be a bug
>
>   <timeless_mbp>  anne: i'm not sure if we want to discuss any of the
>   issues now
>
>   <timeless_mbp>  artb: that's up to you, we have some of the people in
>   the room
>
>   <timeless_mbp>  anne: one of them is the user info protection in the
>   urls
>
>   <timeless_mbp>  … i think microsoft doesn't implement it
>
>   <timeless_mbp>  … and i think the other vendors do
>
>   <timeless_mbp>  … so that you can have [35]http://user:pass@host/...
>
>     [35] http://user:pass@host/...
>
>   <timeless_mbp>  anne: I think the HTTP people want to remove it
>
>   <timeless_mbp>  sicking: I think we could try to remove it
>
>   <timeless_mbp>  sicking: does the spec say they must be supported?
>
>   <timeless_mbp>  anne: the http url spec does mention them
>
>   <timeless_mbp>  anne: does the url get sent to the server?
>
>   <timeless_mbp>  sicking: it might leak in the form of a referer
>   header
>
>   <shepazu>  scribenick: timeless
>
>   sicking: i'm sure the url testsuite ...
>
>   anne: they are mentioned in the spec
>
>   … the spec has user and password arguments
>
>   … which are used to set authorization headers (?)
>
>   … if we don't remove it ...
>
>   anne: there is an issue in the bug database, i think it's the only
>   open issue at this point
>
>   <Zakim>  shepazu, you wanted to describe policy on php in test suites
>
>   shepazu: so dom followed up with the Systems Team on PHP tests
>
>   … we just got confirmation that we will be hosting the php tests
>
>   <Barstow>  ACTION: barstow XHR: add link to bugzilla in PubStatus
>   [recorded in
>   [36]http://www.w3.org/2010/11/02-webapps-minutes.html#action02]
>
>   <trackbot>  Created ACTION-609 - XHR: add link to bugzilla in
>   PubStatus [on Arthur Barstow - due 2010-11-09].
>
>   … any tests that involves PHP will require review by the Systems
>   Team
>
>   … they will be hosted on the load balancing servers
>
>   anne: which servers?
>
>   dom: they'll be hosted on test.w3.org
>   ... it would be helpful if you moved to the mercurial server
>
>   anne: i think there's a version there
>
>   … but probably not up to date
>
>   shepazu: the process will be such that you let us know when there's
>   a specific version you want deployed
>
>   … it will not be deployed until the systems team reviews it
>
>   shepazu: i think this will come up a lot
>
>   anne: there's also the web sockets stuff
>
>   dom: i think that is more complicated and will require more work
>
>   … i think we can manage, it requires more work
>
>   shepazu: for cross domain work, i think we'll need another domain
>
>   adrianba: we already have "test" and "test2" which are cnames
>
>   dom: if you are working on any test suite that has server side
>   things, please get in touch with the Systems Team early
>
>   anne: if you really want to test the really gritty networking stuff
>
>   … I think you will need HTTPS, certificates, DV, EV, OV,...
>
>   shepazu: those are good points
>
>   … Philippe is starting a new testing project
>
>   … so setting up a little test honey pot might be possible
>
>   dom: in general i think what's important is getting things to the
>   REC track, so get in touch with Systems Team earlier rather than
>   later
>
>   <scribe>  ScribeNick: timeless
>
>   artb: anything else about XHR or its testsuite?
>
>   anne: no. apart from asking people to review/give comments
>
>   bryan: is it easy to set up?
>
>   anne: yes, there's a readme
>
>   <dom>  (can we record an action to update the test suite on
>   dvcs.w3.org?)
>
>   artb: based on the feedback you've got so far on the XHR1 candidate
>
>   Action anne update the test suite on dvcs.w3.org
>
>   <trackbot>  Created ACTION-610 - Update the test suite on dvcs.w3.org
>   [on Anne van Kesteren - due 2010-11-09].
>
>   anne: Before going back to last call
>   ... make sure that we have two implementations that pass all the
>   tests
>   ... and that the specification has all the implementations passed
>   that
>   ... so that when we go back to LC we can go to PR after that
>   (skipping CR)
>
>   artb: the third bullet for this hour is a general discussion about
>   testing
>   ... and we've already gone down that path quite a bit
>
>   anne: we could discuss responseArrayBuffer briefly
>   ... i'm not sure we could reach a conclusion now
>
> XHR2 responseArrayBuffer
>
>   sicking: I do have something to say on this
>   ... So, the complicated issue is that...
>   ... there's multiple topics
>   ... the whole ongoing discussion right now about parsing...
>   ... all requests into all response properties
>   ... (Boris Z)
>   ... what i'd like to do is move away from the current situation
>   ... where we parse into multiple properties
>   ... which is the XHR1 behavior
>   ... I want to move to a way where you specify up front which thing
>   you want
>
>   adrianba: I think that makes sense
>   ... so if you know it's coming as JSON or you want it as a Blob, you
>   can specify that
>
>   sicking: obviously we need to retain compatibility with XHR1
>   ... and the stuff where you get a document
>
>   anne: this sounds kind of annoying
>
>   sicking: while it is nice to have things nice to have things parsed
>   into everything
>   ... it's only nice if you don't have to consider all the resources
>   used
>   ... what we're talking about is Document
>
>   anne: but you only need to create Document once it's requested
>   ... you don't have to do it all up front
>
>   sicking: in our implementation
>   ... we'll do charset-decoding differently depending on whether we're
>   parsing into a document or not
>   ... so responseText changes depending on whether you have a document
>   ... and the spec requires this
>   ... everything else, JSON, Blobs, streams...
>
>   anne: streams?
>
>   sicking: we'll end up having to do it
>
>   adrianba: streams for media...
>
>   sicking: you can't set headers without this
>
>   adrianba: or you might want to process the data as it arrives
>
>   [anne was asking about using<video>  ]
>
>   sam: we don't have to convince anne about streams
>   ... more things will be using new content formats
>
>   geoffrey: there will be more and more kinds with time
>
>   anne: this screws with content negotation
>
>   [ scribe laughs ]
>
>   sicking: one of the aspects of my proposal is that you can set
>   .responseType after headers are received
>   ... but before any data has been processed
>
>   anne: how would it work for sync requests/
>
>   sicking: we'd fire events
>
>   anne: but they're blocked by the sync request
>
>   sicking: you can't fire an async request, but you can fire a sync
>   event
>   ... that's trivial implementation-wise
>   ... you just run code on the main thread
>
>   anne: that sounds hairy
>
>   smaug: we explicitly want to get rid of ready state change events
>   ... because that causes hanging in safari
>
>   adrianba: i think it's fine to not support sync requests for this
>   new feature
>   ... because we want to push people toward async
>
>   jonas+sam: for workers sync requests are fine
>
>   anne: i'm saying you're opening a rathole
>
>   mjs: so what are we specifically talking about?
>
>   geoffrey: this was for when we receive content headers
>
>   anne: i don't think we should really fire events during a sync
>   request
>   ... because conceptually that's confusing/seems really weird
>
>   mjs: there's generally a separate thread buffering the data from the
>   network
>
>   sam: the buffering is already happening
>   ... anyone doing network handling on the main thread is probably
>   doing something really wrong anyway
>
>   sicking: i'm suggesting this *only* for workers
>
>   anne: I guess I would have to reference Workers from XHR2
>
>   sam: we kind of think of sync as deprecated in the main context now
>   ... so adding features and having them exposed for the non workers
>   case is kind of like whatever
>
>   mjs: even in workers, i think it makes sense to encourage people to
>   have multiple concurrent requests
>   ... by not providing this feature for sync
>
>   sicking: i'm not sure that this has taken off
>
>   artb: time check
>   ... we have test suites we've already covered
>   ... and you have ...
>
>   sicking: i posted my original proposal on content negotiation to the
>   list
>   ... it's a long thread
>   ... i had one more issue on byte array
>   ... have you seen the proposal on the ecma list
>   ... about another binary format?
>
>   anne: i'm not on the list
>   ... i think it should align with webgl
>
>   <MikeSmith>  sicking, url?
>
>   sicking: it's a long discussion
>   ... i'll try to find the url
>
>   anne: i don't mind removing endianness
>   ... but it would have to be aligned about webgl
>
>   sam: the reason for the endianness is that you want things in host
>   byte order for webgl
>
>   sicking: not all details are worked out yet
>   ... the idea is to have it be fast
>   ... but without exposing platform endianness
>   ... the problem is that you're talking between two languages, JS and
>   GLSL
>   ... david herman is the guy who made the proposal
>
>   <anne>  GLSL = OpenGL Shading Language
>
>   <sicking>
>   [37]http://wiki.ecmascript.org/doku.php?id=strawman:binary_data
>
>     [37] http://wiki.ecmascript.org/doku.php?id=strawman:binary_data
>
>   <sicking>
>   [38]http://wiki.ecmascript.org/doku.php?id=strawman:binary_data_sema
>   ntics
>
>     [38]
> http://wiki.ecmascript.org/doku.php?id=strawman:binary_data_semantics
>
>   <sicking>
>   [39]http://wiki.ecmascript.org/doku.php?id=strawman:binary_data_disc
>   ussion
>
>     [39]
> http://wiki.ecmascript.org/doku.php?id=strawman:binary_data_discussion
>
>   artb: before we go on to DOM Core, I wanted to set aside a few
>   minutes for testing
>
>   <Guest724>  anne , t'es fran�aise ?!
>
>   adrianba: we submitted tests for the webapps and html WGs
>
>   <adrianba>
>   [40]http://dvcs.w3.org/hg/webapps/file/5814514eeba4/tests/DOMEvents
>
>     [40] http://dvcs.w3.org/hg/webapps/file/5814514eeba4/tests/DOMEvents
>
>   adrianba: i'd like to move away from a system where we have a
>   different process per spec for submission
>   ... we have some tests which we have committed to the mercurial
>   repository - i just pasted the link
>   ... when I was talking to doug, he was trying to develop tests
>   alongside the spec
>   ... we/he found that if you develop tests as you develop the spec,
>   it's easier to find spec issues
>   ... there's a question of where to put tests as things are developed
>   ... and keep aware of which things are agreed upon tests. which are
>   under development. which aren't agreed
>
>   sicking: we should try to require tests to be automatically runnable
>
>   <Barstow>  ACTION: barstow work with Team and Chaals on formalizing
>   test suite process for WebApps [recorded in
>   [41]http://www.w3.org/2010/11/02-webapps-minutes.html#action03]
>
>   <trackbot>  Created ACTION-611 - Work with Team and Chaals on
>   formalizing test suite process for WebApps [on Arthur Barstow - due
>   2010-11-09].
>
>   anne: ... whenever possible
>
>   adrianba: i think the work that anne did to refactor the XHR test
>   suite to use the same framework as the HTML tests
>   ... he should receive credit for that, because it made things much
>   easier to review
>
>   sicking: when mozilla started adding tests to a framework
>   ... it made things much better
>   ... So if we have a formalized framework, and we should pick one,
>   and force everyone [in the webapps WG] to use that one
>
>   artb: for new tests...
>
>   shepazu: certainly most of the tests around browser stuff should use
>   the same framework
>   ... there's probably some stuff in W3C outside of browser context
>   where this doesn't make sense
>   ... the SVG group has also agreed to move to the same framework
>   ... with SVG2, things are not going to go into the spec without
>   having tests added
>   ... until we do that, we'll mark things as under review
>   ... I guess i'm just offering a +1 for a common framework as much as
>   possible
>   ... have we talked about testing with WebIDL?
>   ... because if you describe stuff in a spec with webidl, you're
>   going to be able to extract that and do a certain amount of
>   automated tests
>   ... or not?
>
>   sicking: i'm more of a fan of handwritten tests
>   ... i'll believe it when i see it
>
>   dom: there was a perl tool that i mentioned on public-script-coord
>   ...
>   ... that generated tests from idl
>   ... But I agree with jonas that it's better to start with manual
>   tests
>
>   adrianba: the model that creating things is that you can use
>   automatic creation to simplify basic generation of simpler tests to
>   supplement hand-written tests
>
>   sicking: at mozilla we're also looking into automatically testing
>   things that aren't automatically testable
>   ... such as testing interacting with a file picker
>   ... things which require apis which aren't web accessible
>
>   AnssiK: about functional testing... do you have things other than
>   unit testing?
>
>   sicking: what we do is that we expose a lot of stuff to javascript
>   ... to have javascript override the dialog
>   ... we can also fake real clicks on things
>   ... it's being rewritten because the way we did it is not good
>
>   <dom>  [42]perl tool to generate test cases based on WebIDL
>
>     [42]
> http://lists.w3.org/Archives/Public/public-script-coord/2009OctDec/0067.html
>
>   AnssiK: there's a thing called sellenium
>
>    [43]http://en.wikipedia.org/wiki/Selenium_(software) ]
>
>     [43] http://en.wikipedia.org/wiki/Selenium_(software)
>
>   scribe: which is cross browser
>
>   <AnssiK>  s/sellenium/Selenium/
>
>   sicking: we're using a somewhat different approach
>
>   shepazu: when i tried to do test first / test in parallel
>   ... i unfortunately failed
>   ... i couldn't get the resources together in order to do that
>
>   <adam>  Selenium can be automated using something like Hudson
>   [44]https://hudson.dev.java.net/
>
>     [44] https://hudson.dev.java.net/
>
>   shepazu: do people find testing in parallel to develop tests at the
>   same time as developing the spec
>
>   David: with WAC we made sure that there are Test Assertions as you
>   write the spec
>
>   <dom>  [45]A Method for Writing Testable Conformance Requirements
>
>     [45] http://www.w3.org/TR/test-methodology/
>
>   David: the outcome of what you want can be written out as the spec
>   is written
>   ... you have a test description file that links back to the spec
>
>   shepazu: is there interest in imposing this on the WG?
>
>   artb: yes, I took an action to work this out
>   ... we'd put forward a proposal to the WG
>   ... no one objected
>
>   adrianba: i volunteered testing resources
>
>   david: we strongly support any work in testing
>
>   <adrianba>  s/i volunteered testing resources/i volunteer to help
>   define the process proposal/
>
>   david: we've had complaints in WAC, the other stuff has been quite
>   difficult for us to test (for lack of tests)
>
> Web DOM Core
>
>   anne: DOM Level 3 Core was a REC a long time ago
>   ... there's various differences in what web browsers implemented and
>   what the spec says
>
>   [ anne describes differences ]
>
>   <Barstow>  ArtB: Web DOM Core abstract:
>   [46]http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#abstrac
>   t
>
>     [46] http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#abstract
>
>   anne: there are a few things HTML5 currently defines, which I think
>   should be moved back to DOM Core
>   ... like what createElement does
>
>   <shepazu>  [here's a short analysis of a case of WRONG_DOCUMENT_ERR:
>   [47]http://www.schepers.cc/svg/blendups/scriptbridge/scriptbridge-in
>   sertBug.html ]
>
>     [47]
> http://www.schepers.cc/svg/blendups/scriptbridge/scriptbridge-insertBug.html
>
>   anne: and defining what Document.charset/Document.defaultCharset/...
>   are.
>   ... but leaving HTML to define when it sets them
>   ... there's a more ambitious goal of getting rid of AttrNodes
>
>   [ sicking talks about DOM UserData]
>
>   sicking: i'm surprised no one has got requests for them
>
>   sam: we have
>   ... but in the past we've said can't you use set property?
>   ... and that's been good enough for them
>
>   sicking: but you could get conflicts with future specs
>   ... yeah i'm all for getting rid of AttrNodes
>   ... i was talking to travis from Microsoft about it
>   ... we might need to add ownerElement on the Attr
>   ... the main goal is to make them not be nodes
>
>   anne: this would move the namespaceURI away from Node
>
>   sicking: attribute nodes, i know we keep having security issues with
>
>   anne: the other things, it would be nice to get rid of, but it isn't
>   terribly important
>   ... namespaceURI is only relevant for Element and Attr
>
>   sicking: it's useful for simple traversal
>
>   anne: the main reason is to avoid casting in Java
>
>   sicking: forms does the same thing, so you can iterate the
>   forms.elements array
>   ... so you can avoid checking the type before getting properties
>
>   anne: but what would you be doing?
>
>   sicking: ...i don't know...
>
>   artb: so, this afternoon will be IndexDB, chaired by Anne
>
>   sicking: is anyone else planning to try to start removing these
>   things?
>
>   anne: we don't want to lead
>
>   sam: webkit would be interested in trying in nightlies
>
>   anne: we have already removed DOM UserData by not implementing it
>
>   sam: I have done the same for years, by not implementing it
>
>   anne: we are not actively removing things, but we have tried to
>   restrain ourselves from implementing things
>   ... we would really like the Attr thing
>
>   sam: Are there any NodeLists that return Nodes other than Elements?
>
>   anne: there were. but I tried to kill those
>   ... maybe there are no longer
>
>   Break for Lunch
>
>   <anne>  arun, you there?
>
>   <anne>  arun, you want to dial in for Indexed DB?
>
>   <MikeSmith>  arun: you got a Skype ID?
>
>   <arun>  Hi there Mike
>
>   <MikeSmith>  hey man
>
>   <arun>  MikeSmith: I'd like to dialin if possible.
>
>   <arun>  anne: I'd like to dial in if possible.
>
>   <MikeSmith>  scribe: MikeSmith
>
> IndexedDB
>
>   <adam>  Adam Boyet - Boeing
>
>   Paulo: there is a list of topics on the mailing list
>
>   <anne>
>   [48]http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/04
>   13.html
>
>     [48]
> http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0413.html
>
>   <adrianba>
>   [49]http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/04
>   13.html
>
>     [49]
> http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0413.html
>
>   s/Paulo/Pablo/
>
>   pablo: shall we do Keys?
>   ... keys and tables… what we have today is simple keys
>
>   … compound keys, custom orders
>
>   <anne>  Indexed DB:
>   [50]http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html
>
>     [50] http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html
>
>   …e.g., by date + by integer
>
>   … key value would be an array
>
>   sicking: not sure what syntax we should use
>
> Keys
>
>   sicking: one proposal was array of "key paths"
>
>   jorlow: compound keys, being able to have arrays in your keys;
>   another thing is compound indexes
>
>   pablo: can't we reduce that to the same problem?
>
>   jorlow: one or part of the structure of the DB, one is something you
>   can do more ad hoc
>
>   … key could be array one time, a string or something else the next
>
>   <anne>  who is +1.408.446.aabb? Nikunj?
>
>   <Nikunj>  Nikunj
>
>   <anne>  kk
>
>   <anne>  screw you Zakim
>
>   pablo: rule of strictly sorting by type, then sort by value is very
>   sharp
>
>   jorlow: another question is, what do we want to do if you ahve a key
>   path to "foo" and you insert an item that doesn't include a "foo"
>
>   [discussion about what to do if a key path resolves to an array]
>
>   sicking: every place where we currently allow values we should also
>   allows arrays
>
>   [discussion about difficulty of implementing]
>
>   [sicking demonstrates with some code]
>
>   Option A is an array is just a single value
>
>   s/Option A/pablo: Option A/
>
>   jorlow: example is that people can have multiple names, and you can
>   construct an index such that multiple names map to the same person
>
>   pablo: I am not sure about composite keys made of arrays
>
>   sicking: the 2nd case is multiple records pointing to the same
>   object store
>
>   <Nikunj>  I thought that composite key means there are many parts to
>   a key and that the parts are obtained from different paths
>
>   <Nikunj>  The discussion seems to be about a single path resolving to
>   multiple values
>
>   sicking, see Nikunj comment
>
>   sicking: Nikunj, I agree with your interpretation
>
>   jorlow: yeah, agreed
>   ... what are we going to do in teh case where you are inserting a
>   value that doesn't include something for a key path
>
>   e.g., you are inserting a person and you don't include a first name,
>   and the first name is the key
>
>   <Nikunj>  Multiple keys in an index pointing to a single object is
>   not the same use case as compound key
>
>   jorlow: pablo, you seem to be worried that any handling of arrays is
>   going to be a lot of work
>
>   <Nikunj>  The latter is about constructing a key serialization from
>   multiple keypaths
>
>   <Nikunj>  The former changes the meaning of a key
>
>   <Nikunj>  there is a difference between composite and compound keys
>
>   <Nikunj>  See [51]http://en.wikipedia.org/wiki/Compound_key
>
>     [51] http://en.wikipedia.org/wiki/Compound_key
>
>   sicking: in solution A we can have a mix of values and arrays.
>
>   jorlow: should be allow keys to be indexes?
>   ... the only use case is, search on multiple keys
>   ... use case 1 is, my DB has people in it, with first name and last
>   name
>
>   … and I want to search for everybody who has both a certain first
>   name and a certain last name
>
>   jorlow: use case 2 is @@something @@
>   ... 3rd possibility is first-name entry, last-name entry, then an
>   entry that has both that duplicates the first two
>
>   <jorlow>
>   [52]https://docs.google.com/document/edit?id=1IImAV3hzdqhaiaYfKzb-GW
>   lCgKUDQX3wiXPkqjFFFWg&hl=en&authkey=CIHTwIIM
>
>     [52]
> https://docs.google.com/document/edit?id=1IImAV3hzdqhaiaYfKzb-GWlCgKUDQX3wiXPkqjFFFWg&hl=en&authkey=CIHTwIIM
>
>   jorlow: choice is, do you want users to have to duplicate their
>   data? or do you want to have duplicated indexes
>
>   s/@@something @@/database contains people, find person with name
>   "foo", be that first or last name/
>
>   anne: so there's no AND ?
>
>   jorlow: there's no query language
>
>   Nikunj: I am not sure you need composite keys nor compound keys
>
>   jorlow: specifying a join language is a very big task
>
>   … for that, you can take whatever we've done so far here and
>   multiply it by 100
>
>   Nikunj: I am looking for a join _primitive_
>
> internationalization
>
>   pablo: scenario is, you expect sort order to be in accord with your
>   language
>
>   <Nikunj>  See
>   [53]http://www.w3.org/TR/2009/WD-WebSimpleDB-20090929/#entity-join
>   for a description of the join primitive
>
>     [53] http://www.w3.org/TR/2009/WD-WebSimpleDB-20090929/#entity-join
>
>   sicking: question is, are we happy with having a language on a
>   DB-wide basis? [as opposed to per object store]
>
>   <anne>  [54]http://unicode.org/reports/tr10/
>
>     [54] http://unicode.org/reports/tr10/
>
> Dynamic transactons:
>
>   jorlow: my vote is, don't do it
>
>   <Nikunj>  What is the current topic?
>
>   <anne>  Transactions
>
>   <anne>  ... all transactions have time-consistency
>
>   <anne>  ... how implementations achieve that is up to the
>   implementation
>
>   <anne>  ... for writers you can only have one writer happening at the
>   time
>
>   <anne>  ... unless they are separate object stores/tables
>
>   <anne>  ... you could figure out the overlap and be very smart...
>   whatever (something like that)
>
>   <anne>  ... should be some more non-normative text that explains this
>
>   <anne>  JS: if you start two transactions; is there any guarantee
>   with respect to order?
>
>   <anne>  JO: I don't think so; get weird behavior with locking; would
>   be shame as we get less concurrency
>
>   <anne>  JS: what if there is overlap
>
>   <anne>  JS: read, readrequest, write, writerequest
>
>   <anne>  JO: no order guaranteed
>
>   <anne>  JS: sounds very racy
>
>   <anne>  JO: if you cared do not start them at the same time
>
>   <anne>  Pablo: I don't think it is strictly a race
>
>   <anne>  JO: what is the use for starting them at the same time?
>
>   <anne>  Pablo: there should not be starvation
>
>   <anne>  JS: already says that
>
>   <anne>  JS: in Firefox there's no raceness and you always know the
>   order
>
>   <anne>  JS: and no starvation either
>
>   <anne>  JO: I can't think of any reason you start these and expect
>   them to run in the same order
>
>   <anne>  thank you darobin
>
>   <anne>  Pablo: workers also introduce these problems
>
> synchronous API
>
>   <anne>  within one worker you can only have one transaction
>
>   <anne>  that assumes requiring locks is in order
>
>   <anne>  make minutes
>
>   <mjs>  ScribeNick weinig
>
>   <weinig>  js: you already have to lock tables
>
>   <weinig>  js: we have to make the transaction function take a
>   callback
>
>   <weinig>  pablo: why can't we make the second transaction fail
>
>   <weinig>  js: it would be very confusing for two independent
>   libraries to interact together
>
>   <weinig>  pablo: that syntax seems very unwieldily
>
>   <weinig>  jo: the function is just defining scope
>
>   <weinig>  js: transactions within the function will throw
>
>   <weinig>  jo: is anyone planning to implement sync
>
>   <weinig>  jo: should we have a warning in the spec?
>
>   <weinig>  jo: editors should try and keep sync and async in sync
>
>   <weinig>  pablo: is everyone planning on doing async in main context
>   and sync and async in workers?
>
>   <weinig>  everyone: yes
>
>   <Nikunj>  can implementors provide an update on their implementation
>   status/plans
>
>   <weinig>  pablo: should transactions be allowed in transactions?
>
>   <weinig>  jo: maybe we should have an open nested transaction
>
>   <weinig>  pablo: everything you would need to do you can do off the
>   transaction
>
>   <weinig>  pablo: lets ignore the last few lines
>
>   <anne>  scribe: anne
>
> Bugzilla
>
>   RESOLUTION: not automatically assign to Nikunj; MikeSmith to follow
>   up
>
>   We have room number 4 all day tomorrow
>
>   times to be announced
>
>   <MikeSmith>  if the problem is that Nikunj is not in the tracker DB I
>   can add him now
>
> quotas
>
>   Pablo: by default we are not going to let apps fill the disk; so
>   what to do
>
>   <MikeSmith>  trackbot, status?
>
>   Pablo: lots of degrees of freedom
>
>   MikeSmith, it would be nice if it was assigned to a nobody instead
>   since Nikunj is not the only editor
>
>   <MikeSmith>  hai
>
>   <MikeSmith>  I will change it now
>
>   Pablo: bytes are not necessarily meaningful as a unit
>
>   great
>
>   Pablo: first attempt to use the database; anything the app needs to
>   do?
>
>   SQL DB estimated size argument was very confusing
>
>   Dealing with size constraints:
>
>   1) no API impact
>
>   Chrome has a hard limit (with a non-specced error)
>
>   conclusion seems to be that some kind of quota error is needed
>
>   the spec does not say you create the index asynchronously
>
>   JO: i think it is implied
>
>   Pablo: it should be explicit
>
>   JO: i think it is in there, maybe should be more explained
>   ... if it fails it fails the transaction
>
>   Does there need to be a way for asking for more space?
>
>   adrianba: in SilverLight we wanted to give the app more control
>   ... if e.g. you download a huge file you do not want the UA to have
>   to ask and ask again
>   ... but instead allocate once
>
>   JO: use cases are caching and some kind of permanent storage (i.e.
>   offline written email)
>
>   Pablo: impossible for us to decide
>
>   s/permanent/persistent/
>
>   JO: in Chrome we plan to group APIs together
>   ... if you get 10 MB you can use it for several APIs
>
>   AvK: for the hint for the pre-allocation of memory case it should be
>   a generic API if we are heading in that direction
>
>   JO: for the persistant vs temporary case that should be noted on the
>   object store
>   ... maybe change createObjectStore (or something like that) to take
>   this as parameter
>
> blobs
>
>   adrianba: how long do blobs persist?
>
>   JS: tied to the Window object
>
>   Eric: if you want to change a Blob you create a new one
>   ... you cannot create a File at the moment
>   ... a file has a last modified time and a name
>
>   Pablo: I'm assuming when you store it in the DB it is a copy
>
>   JS: I hope Indexed DB to be enough
>   ... not need a File System
>   ... I don't want File System to have a capability that Indexed DB
>   does not
>
>   which is that you can modify a file that is stored
>
>   (if the scribe gets it correctly)
>
>   [questions on this topic are best asked on the list]
>
> Indexed DB Last Call
>
>   JO: should we set goals
>
>   adrianba: address the existing issues
>
>   JO: full text search is important
>   ... not gonna be efficient with what we have now
>   ... full text search is extremely important to Google
>
>   <arun>  Full text search was important to external developers as
>   well.
>
>   JO: I hope that one or two changes to the API can make this possible
>   ... I want to get proof first, before adding something to the
>   specification
>
>   synchronizing...
>
>   Pablo: some kind of tracking
>
>   tombstones?
>
>   [further discussion on list]
>
>   arun, you still here?
>
>   <arun>  anne, yep
>
>   cool
>
>   I guess Jonas can go through the File API mostly
>
>   might be tricky over the phone
>
>   <arun>  anne, it's cool. I can hear you guys really clearly
>
>   <arun>  anne, if I need to speak I'll just speak up.
>
>   <arun>  anne, you can refer to the email I sent about agenda stuff if
>   you like.
>
>   [55]http://www.w3.org/2008/webapps/wiki/TPAC2010
>
>     [55] http://www.w3.org/2008/webapps/wiki/TPAC2010
>
>   [56]http://dev.w3.org/2006/webapi/FileAPI/
>
>     [56] http://dev.w3.org/2006/webapi/FileAPI/
>
> File API
>
>   <arun>  anne is the URL string trouble maker
>
>   <jorlow>  scribe: jorlow
>
>   anne, doesn't like adding 2 more methods to window
>
>   arun, any other solution is back to the drawing board
>
>   anne, vendor prefixing might help limit usage
>
>   anne, but we still need to find the right solution
>
>   ericu, stuff put on the global object so that stuff is tied to the
>   lifetime of the window
>
>   jonas: when window is nagivated away, all urls are revoked
>
>   sam: you can do that regaurless of the syntax
>
>   ericu: what about if you pass from one window to another? this is
>   more explicit
>
>   sam, disagrees
>
>   jonas, is fine with other suggestions. thinks reusing url is weird
>   because it's only somewhat related
>
>   sam, so you could just have a blobURI object
>
>   jonas, an object might make sense....something about domURL
>
>   anne, don't you want to stringify it as well?
>
>   jonas, no
>
>   jonas, you'd create an object from a string
>
>   anne, you're still not solving the problem
>
>   jonas, trying to solve 2 problmes
>
>   jonas, something so we don't create strings...for that, need to
>   create a new type of interface...call it domURL for now
>
>   anne, domURL could be some union type of blob and stream
>
>   jonas, don't want create to be through some constructor and revoke
>   through a completely different api
>
>   jonas: we coudl create a global dummy object with both methods
>
>   arun: is it worth make global dummy object the same thing being
>   specced by adam barth
>
>   no
>
>   jonas: abarth's thing is to solve parsing urls. this isn't want we
>   need to do with blob urls
>
>   anne: not so sure
>
>   jonas: there's a vague resemblance given that they both revolve
>   around URLs
>
>   sam: agrees
>   ... especially since adam's thing doens't exist yet
>   ... can we discuss other things?
>
>   jonas: the proposed solution is some global object where we put 2
>   functions
>
>   anne: is there some existing place we could put them?
>
>   sam: maybe window.blob? but you want to do it for stream too so
>   maybe that's not a good place
>
>   ericu and others: k, let's move on
>
>   <timeless>  s/coudl/could/
>
>   <timeless>  s/doens't/doesn't/
>
>   sam: 2 questions. file list has been redefined to be a sequence of
>   files rather than a simple object. our implementation has file lists
>   like node lists. sequence doesn't have an item function.
>
>   anne: cameron said sequence isn't for that type of thing
>
>   jonas: saw hixie open a bug on something similar today
>
>   sam: in the mean time, should we go back to the simple interface?
>
>   anne: file lists should probably follow others
>
>   general agreement
>
>   sam: file reader + write have event handler attributes but don't
>   inherit from event target.
>
>   arun: it does
>
>   sam: sees it...what about writer?
>
>   ericu: if so, it's a bug
>
>   anne: we should have some consistency
>
>   sam: using implements probably makes sense (vs. inheriting) in the
>   spec
>
>   arun: agrees with sam
>
>   anne: XHR inherits
>
>   sam: in webkit, event target isn't in the prototype chain
>   ... does it affect it though?
>
>   anne: maybe xhr should change
>
>   jonas: no advantage to not inheriting
>
>   sam: let's avoid multiple inheritance
>
>   jonas: agrees
>   ... but most of these thigns don't inherit
>
>   anne: XHR does
>
>   jonas: but you can add it to the bottom of the chain
>
>   <timeless>  s/thigns/things/
>
>   sam: everything in svg uses multiple inheritance
>   ... we should probably bring this up as a WebIDL issue
>
>   jonas: it's unfortuate you can't add stuff to event target prototype
>
>   sam: if we could solve multiple inheritance in a good way, then
>   maybe it's a non-issue
>   ... jonas, are you coming to tc39?
>
>   jonas: yes
>
>   anne: does it have anything more on file api?
>
>   s/does it/do we/
>
>   <MikeSmith>  s/Transactions/scribe: anne/
>
>   jonas: request from google...when you request url, wants to do
>   something related to content type (didn't understand)
>
>   i didn't understand
>
>   <arun>  arun: do we still have URL string dereferencing behavior?
>
>   ericu: right now content type is a property of blob
>   ... we could add these properties to blob directly
>
>   arun: only contnet disposition was asked for
>   ... just like content type
>
>   <MikeSmith>  i/What is the current topic/scribe: anne
>
>   <timeless>  s/contnet/content/
>
>   <MikeSmith>  dunno
>
>   jonas: darin fisher has asked for content disposition. jonas has
>   said to use file save back to him
>   ... and point the file saver to the blob directly
>
>   ericu: we want blob url to work just like any other
>
>   <arun>  arun: right, so instead of Content-Disposition on Blob URLs,
>   you have a URL argument to the FileSave constructor.
>
>   ericu: gmail offline, for example, wants to be able to view and
>   download with similar code. just different urls. presentation layer
>   stays same, but backend just gives different urls
>
>   sam: not sure he understands why you'd create a url from a blob and
>   pass it to an XHR
>
>   jonas: not sure anyone suggested this
>
>   sam: isn't that the reason to set headers: to get it through XHR?
>
>   jonas: no, it was just to explain
>   ... iframes care about headers
>   ... to do gmail file saving, create iframe, take blob, create url,
>   content dis. header, iframe looks at that header, it works
>
>   ericu: can't you do that today?
>   ... only need iframe trick if you don't have content disposition
>   header
>   ... wait...hm...
>
>   jonas: link with target: _blank
>
>   sam: that opens a window
>
>   anne: behavior varries
>
>   sam: agreed
>   ... very marginal use case
>
>   jonas: it's a very roundabout way of triggering file save dialog
>
>   <arun>  arun: +1 to sam, sicking
>
>   ericu: urls have these properties already
>   ... making offline urls work just like online urls seems nice
>
>   sam: they're more a property of the resource, not the url itself
>
>   jonas: it's actually a property of the person initiating the load
>   ... make file save support taking url
>   ... same architecture for blobs and urls
>
>   sam: some browsers default behavior is not prompt and download to
>   directory
>   ... so that'd behave differently
>   ... iframe with content disposition treated as download, file saver
>   treated as save as
>
>   jonas: i'm not sure we'd behave differently
>
>   timeless: we shipped that behavior 2+ years ago
>
>   <timeless>  [we = Mozilla/Firefox]
>
>   ericu: if you want file saver to do the default, that's another
>   behavior
>
>   jonas: if people only want a download mechanism, we should do it
>   right not extend hack
>
>   arun: hack exists for http reasons
>   ... ericu's "uber question" is a good one
>
>   ericu: allowing all headers in seems cleaner
>
>   anne: it's complicated if we only care about content disposition
>
>   sam: setting something like x frame options could be useful
>   ... my recollection are that most of these things are attributed to
>   the resource not the url
>   ... it seems a bit hackish to set headers on a blob
>
>   ericu: agrees. a blob might never be used as a url
>   ... in some cases, the headers are more assicated with the url
>   rather than the resource itself
>
>   jonas: this discussion has gotten a bit meta
>   ... should the headers arguments exist on the blob or create url
>   function
>
>   sam: that's one question. the other is whether we need the headers
>
>   ericu: likes headers. if we have them, put them on createURL
>   function
>
>   anne: let's move discussion to list
>   ... talks about his sneaky plan
>
>   ericu: we can go back to file after writer/system questions
>
>   <timeless>  the example for using URL instead of Blob to have the
>   bits is to match Gmail where an image attachment has View and
>   Download links - two urls to the same blob data
>
>   ericu: doesn't have any issues to bring up
>
>   anne: can you give a quick introduction?
>
>   ericu: does said introcution...
>
>   <timeless>  s/cut/duct/
>
> FileSaver
>
>   <anne>  s/FileSaver/File: Writer and File: Systems and Directories/
>
>   sam: so file writer sync doesn't not pop up a dialog?
>
>   <timeless>  s/introcution/introduction/
>
>   ericu: yup
>   ... this is just a writing interface...doesn't describe how to get
>   access
>   ... file system spec gives another away to get access to a file
>   ... otherwise the only way is file saver
>   ... file system is like a chrooted environment to create dirs,
>   files, etc
>   ... file system is good if your data isn't structured
>   ... game designers want this for art assets, for example
>
>   sam: what about indexedb
>
>   jorlow: or app cache
>
>   ericu: not good match for app cache...it's all or nothing
>
>   jonas: thinks system is not needed
>   ... because of indexedDB
>
>   sam: data cache or an extension to app cache might have worked as
>   well
>
>   ericu: yes
>
>   sam: waht about various databases
>
>   <timeless>  s/waht/what/
>
>   sam: jonas's face was scary
>
>   ericu: it's a matter of taste
>
>   sam: seems like adding this much API surface area for a matter of
>   taste is bad taste
>
>   ericu: it's more than just taste
>
>   <arun>  arun: I agree with ericu about it being a matter of taste.
>   Some like file system based metaphors, and some like databases for
>   everything.
>
>   ericu: sharing data with apps outside of the browser is good too
>
>   sam: indexedDB could store files in the file system if it wanted to
>
>   ericu: that seems odd. no hierarchy
>
>   jonas: yeah, no meta data
>
>   ericu: gives a use case
>
>   sam: if that's a use case, it should be explicit in spec
>   ... and what about when file system doesn't exist
>
>   ericu: that's one reason to make it explicit in the spec
>   ... it's a significant motivator, but not required

Correction, I said "that's one reason NOT to make it explicit in the
spec".  I think Sam's right that it's worth adding the use case to the
non-normative text in the spec, but I don't think it should be an
implementation requirement.

>   jorlow: you could store meta data ad-hoc in indexedDB if you wanted
>   to
>
>   jonas: the meta data will be understandable by other apps
>   ... hurdle: some people are nervous about allowing websites to save
>   stuff to a known location
>
>   sam: we probably want to add changes to mac os X to allow ..?
>
>   ericu: in current implementation, files not saved in known location
>   ... describes the hack
>   ... many apps know how to scan a hierarchy of dirs (that can scan it
>   in)
>
>   timeless: then you just exploit some app like iTunes or picassa
>
>   adrianba: what about social engineering
>
>   ericu: opening a file deep in the chrome profile dir...?
>   ... and your av software should still run on it
>
>   adrianba: they have support for knowing the source of the download
>
>   <timeless>  s/picassa/Picasa/
>
>   sam: mac os x too
>
>   jorlow: can't the file system api just set the bits
>
>   <timeless>  windows too
>
>   adrianba: we distinguish between url and site
>
>   ericu: this makes it slightly harder, but it's not a fundamental
>   issue
>
>   adrianba: allowing a web application to save something without
>   immediate consent of user...then social engineering
>
>   <timeless>  [ such as attacking Sherlock, Google Desktop Search ]
>
>   ericu: it's a valid concern and i understand. you might just need to
>   tweak the reputation system a bit to handle this case
>
>   sam: my issue is not security, it's that we already have a lot of
>   storage options
>   ... unnecessary risk to throw 2 new APIs at the web at once
>
>   <arun>  OK big +1 to weinig
>
>   ericu: well it's not there yet and it won't necessarily be popular
>
>   sam: but it can never be removed
>
>   jorlow: isn't it behind prefix
>
>   timeless: that doens't matter much
>
>   ericu: and actually our implementation is not behind prefix
>   ... which is a fair objection
>   ... a number of devs asked for it
>
>   sam: web sql is same
>
>   <timeless>  s/doens't/doesn't/
>
>   sam: we should have been more careful and not do it
>   ... has actual question
>   ... file saver sync doesn't seem to have an actual interface
>   attached to it?
>
>   ericu: will fix it
>
>   sam: from worker, would you pop up save dialog
>   ... what window would it be attached to
>
>   ericu: shared worker is an odd case
>
>   jorlow: brought up more shared worker issues similar
>
>   ericu: yeah...we need to fix some stuff
>
>   jonas: want file save to be able to handle the url
>   ... content disposition is a hack, so it'd be nice to move away from
>   it
>
>   <arun>  Yeah; while we hash out headers on Blob URIs, I think it's
>   good to allow FileSaver to have a URL argument
>
>   sam: people already hack around it, iframe trick might as well
>   become official
>   ... anne are you editing progress events?
>   ... is there going to be some way to say some interface implements
>   something...rather than repeating the work for each progress event
>
>   jonas: there's some web idl way to say supplemental, but reverse
>
>   ericu: onload start, and that doesn't make sense when you're writing
>
>   <anne>  [57]http://www.w3.org/TR/progress-events/
>
>     [57] http://www.w3.org/TR/progress-events/
>
>   jonas: interesting situation when you want progress events for
>   something other than loads since much of them have load in the name
>
>   anne: they're actually specced to be pretty vague
>   ... can't rename them at this point
>
>   adrianba: could you have multiple names for something
>
>   sam: this is a bad idea because events are expensive, therefore
>   firing 2 events is expensive
>   ... we've done this for focus and DOM (yell) Focus
>
>   mjs: you can't actually alias because of add event listener's
>   semantics
>
>   jonas: agreed, aliasing is bad
>
>   anne: the event names are just suggestions
>   ... you can call your events whatever you want
>
>   jonas: it makes sense to do things this way
>
>   sam: should they be save start?
>
>   ericu: filewriter derives from this and uses the same events
>
>   jonas: the interface names are fully generic
>
>   anne: interface still has loaded
>
>   ericu: I think I just put done?
>   ... going to fix the spec
>
>   mjs: we should change the syntax of html
>
>   <mjs>  </sarcasm>
>
>   ericu: taking a step back....
>
>   sam: when people implement event listeners, the event they get will
>   be a little funny because it has words like loaded
>
>   anne: inherited progress events from svg...no one backed me up
>
>   mjs: lots of bike shedding
>
>   jonas: it sucks to add aliases
>
>   sam: maybe add progress of loaded that calls the same underlying
>   function
>   ... bytes progressed maybe?
>
>   jonas: just use progress
>
>   anne: we do have some aliased properties elsewhere I guess
>   ... let's leave "early"
>
>   anne's chairing skillz are celebrated
>
> Summary of Action Items
>
>   [NEW] ACTION: barstow ask Doug for a pointer to Google's "Before
>   Input Proposal" [recorded in
>   [58]http://www.w3.org/2010/11/02-webapps-minutes.html#action01]
>   [NEW] ACTION: barstow work with Team and Chaals on formalizing test
>   suite process for WebApps [recorded in
>   [59]http://www.w3.org/2010/11/02-webapps-minutes.html#action03]
>   [NEW] ACTION: barstow XHR: add link to bugzilla in PubStatus
>   [recorded in
>   [60]http://www.w3.org/2010/11/02-webapps-minutes.html#action02]
>
>   [End of minutes]
>
>
>
>
Received on Friday, 5 November 2010 00:35:07 GMT

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