WebApps F2F Meeting -- 02 Nov 2010

<Barstow> ScribeNick: MikeSmith

<Barstow> Scribe: Mike_Smith

<Barstow> Date: 2 November 2010

<scribe> scribe: MikeSmith

DOM3 Events

<shepazu> http://www.w3.org/2008/webapps/track/products/2

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

-> http://getfirebug.com/wiki/index.php/Console_API 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: 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: 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> http://bitbucket.org/ms2ger/domparser

<ArtB> ACTION: barstow ask Doug for a pointer to Google's "Before Input Proposal" [recorded in 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> 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> http://tc.labs.opera.com/apis/XMLHttpRequest/ and 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> 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> 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 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 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> http://wiki.ecmascript.org/doku.php?id=strawman:binary_data

<sicking> http://wiki.ecmascript.org/doku.php?id=strawman:binary_data_semantics

<sicking> 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> 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 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> perl tool to generate test cases based on WebIDL

AnssiK: there's a thing called sellenium

[ 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 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> A Method for Writing Testable Conformance Requirements

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: 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: 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> http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0413.html

<adrianba> 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: 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 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> 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 http://www.w3.org/TR/2009/WD-WebSimpleDB-20090929/#entity-join for a description of the join primitive

sicking: question is, are we happy with having a language on a DB-wide basis? [as opposed to per object store]

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

http://www.w3.org/2008/webapps/wiki/TPAC2010

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

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

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

- DRAFT -

WebApps F2F Meeting

02 Nov 2010

Attendees

Contents