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

Minutes from WebApps' 2 November 2010 meeting

From: Arthur Barstow <art.barstow@nokia.com>
Date: Wed, 03 Nov 2010 08:57:12 +0100
Message-ID: <4CD115D8.9010108@nokia.com>
To: public-webapps <public-webapps@w3.org>
The draft minutes from WebApps' November 2 meeting in Lyon are available 
at the following and copied below:


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


           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


           Mike_Smith, MikeSmith, anne, jorlow


      * [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


      [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


    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

    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

    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

    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

    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

    anne: I don't think labeling them as deprecated helps us all that

    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

    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

    shepazu: and right now, Mozilla has a related API they have have

    … 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/

    <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

    <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

      [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

    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


      [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

    … 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

    <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

    <timeless_mbp>  anne: yeah, it was the second link i posted


      [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

    <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

    <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

    <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

    <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

    … 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

    <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

    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
    ... and that the specification has all the implementations passed
    ... 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
    ... 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
    ... 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
    ... 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
    ... because conceptually that's confusing/seems really weird

    mjs: there's generally a separate thread buffering the data from the

    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
    ... 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
    ... david herman is the guy who made the proposal

    <anne>  GLSL = OpenGL Shading Language


      [37] http://wiki.ecmascript.org/doku.php?id=strawman:binary_data


      [38] http://wiki.ecmascript.org/doku.php?id=strawman:binary_data_semantics


      [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


      [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

    <trackbot>  Created ACTION-611 - Work with Team and Chaals on
    formalizing test suite process for WebApps [on Arthur Barstow - due

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

    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/

    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#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:
    sertBug.html ]

      [47] http://www.schepers.cc/svg/blendups/scriptbridge/scriptbridge-insertBug.html

    anne: and defining what Document.charset/Document.defaultCharset/...
    ... 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

    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


    <adam>  Adam Boyet - Boeing

    Paulo: there is a list of topics on the mailing list


      [48] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0413.html


      [49] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0413.html


    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

    …e.g., by date + by integer

    … key value would be an array

    sicking: not sure what syntax we should use


    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

    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

    … 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


      [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_


    pablo: scenario is, you expect sort order to be in accord with your

    <Nikunj>  See
    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

    <anne>  ... for writers you can only have one writer happening at the

    <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

    <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

    <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

    <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

    <weinig>  pablo: lets ignore the last few lines

    <anne>  scribe: anne


    RESOLUTION: not automatically assign to Nikunj; MikeSmith to follow

    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


    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


    Pablo: first attempt to use the database; anything the app needs to

    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


    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


    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

    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


    Pablo: some kind of tracking


    [further discussion on list]

    arun, you still here?

    <arun>  anne, yep


    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


      [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


    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

    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

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

    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

    sam: that's one question. the other is whether we need the headers

    ericu: likes headers. if we have them, put them on createURL

    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/


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

    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

    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

    jorlow: you could store meta data ad-hoc in indexedDB if you wanted

    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

    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

    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

    <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

    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
    ... 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
    [NEW] ACTION: barstow work with Team and Chaals on formalizing test
    suite process for WebApps [recorded in
    [NEW] ACTION: barstow XHR: add link to bugzilla in PubStatus
    [recorded in

    [End of minutes]
Received on Wednesday, 3 November 2010 07:57:54 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:28 UTC