See also: IRC log
<Barstow> ScribeNick: MikeSmith
<Barstow> Scribe: Mike_Smith
<Barstow> Date: 2 November 2010
<scribe> scribe: MikeSmith
<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
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
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
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
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)
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
<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
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: 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 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/
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
<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
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
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
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]
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/
<arun> anne is the URL string trouble maker
<jorlow> scribe: jorlow
anne, doesn't like adding 2 more methods to window
arun, any other solution is back to the drawing board
anne, vendor prefixing might help limit usage
anne, but we still need to find the right solution
ericu, stuff put on the global object so that stuff is tied to the lifetime of the window
jonas: when window is nagivated away, all urls are revoked
sam: you can do that regaurless of the syntax
ericu: what about if you pass from one window to another? this is more explicit
sam, disagrees
jonas, is fine with other suggestions. thinks reusing url is weird because it's only somewhat related
sam, so you could just have a blobURI object
jonas, an object might make sense....something about domURL
anne, don't you want to stringify it as well?
jonas, no
jonas, you'd create an object from a string
anne, you're still not solving the problem
jonas, trying to solve 2 problmes
jonas, something so we don't create strings...for that, need to create a new type of interface...call it domURL for now
anne, domURL could be some union type of blob and stream
jonas, don't want create to be through some constructor and revoke through a completely different api
jonas: we coudl create a global dummy object with both methods
arun: is it worth make global dummy object the same thing being specced by adam barth
no
jonas: abarth's thing is to solve parsing urls. this isn't want we need to do with blob urls
anne: not so sure
jonas: there's a vague resemblance given that they both revolve around URLs
sam: agrees
... especially since adam's thing doens't exist yet
... can we discuss other things?
jonas: the proposed solution is some global object where we put 2 functions
anne: is there some existing place we could put them?
sam: maybe window.blob? but you want to do it for stream too so maybe that's not a good place
ericu and others: k, let's move on
<timeless> s/coudl/could/
<timeless> s/doens't/doesn't/
sam: 2 questions. file list has been redefined to be a sequence of files rather than a simple object. our implementation has file lists like node lists. sequence doesn't have an item function.
anne: cameron said sequence isn't for that type of thing
jonas: saw hixie open a bug on something similar today
sam: in the mean time, should we go back to the simple interface?
anne: file lists should probably follow others
general agreement
sam: file reader + write have event handler attributes but don't inherit from event target.
arun: it does
sam: sees it...what about writer?
ericu: if so, it's a bug
anne: we should have some consistency
sam: using implements probably makes sense (vs. inheriting) in the spec
arun: agrees with sam
anne: XHR inherits
sam: in webkit, event target
isn't in the prototype chain
... does it affect it though?
anne: maybe xhr should change
jonas: no advantage to not inheriting
sam: let's avoid multiple inheritance
jonas: agrees
... but most of these thigns don't inherit
anne: XHR does
jonas: but you can add it to the bottom of the chain
<timeless> s/thigns/things/
sam: everything in svg uses
multiple inheritance
... we should probably bring this up as a WebIDL issue
jonas: it's unfortuate you can't add stuff to event target prototype
sam: if we could solve multiple
inheritance in a good way, then maybe it's a non-issue
... jonas, are you coming to tc39?
jonas: yes
anne: does it have anything more on file api?
s/does it/do we/
<MikeSmith> s/Transactions/scribe: anne/
jonas: request from google...when you request url, wants to do something related to content type (didn't understand)
i didn't understand
<arun> arun: do we still have URL string dereferencing behavior?
ericu: right now content type is
a property of blob
... we could add these properties to blob directly
arun: only contnet disposition
was asked for
... just like content type
<MikeSmith> i/What is the current topic/scribe: anne
<timeless> s/contnet/content/
<MikeSmith> dunno
jonas: darin fisher has asked for
content disposition. jonas has said to use file save back to
him
... and point the file saver to the blob directly
ericu: we want blob url to work just like any other
<arun> arun: right, so instead of Content-Disposition on Blob URLs, you have a URL argument to the FileSave constructor.
ericu: gmail offline, for example, wants to be able to view and download with similar code. just different urls. presentation layer stays same, but backend just gives different urls
sam: not sure he understands why you'd create a url from a blob and pass it to an XHR
jonas: not sure anyone suggested this
sam: isn't that the reason to set headers: to get it through XHR?
jonas: no, it was just to
explain
... iframes care about headers
... to do gmail file saving, create iframe, take blob, create
url, content dis. header, iframe looks at that header, it
works
ericu: can't you do that
today?
... only need iframe trick if you don't have content
disposition header
... wait...hm...
jonas: link with target: _blank
sam: that opens a window
anne: behavior varries
sam: agreed
... very marginal use case
jonas: it's a very roundabout way of triggering file save dialog
<arun> arun: +1 to sam, sicking
ericu: urls have these properties
already
... making offline urls work just like online urls seems
nice
sam: they're more a property of the resource, not the url itself
jonas: it's actually a property
of the person initiating the load
... make file save support taking url
... same architecture for blobs and urls
sam: some browsers default
behavior is not prompt and download to directory
... so that'd behave differently
... iframe with content disposition treated as download, file
saver treated as save as
jonas: i'm not sure we'd behave differently
timeless: we shipped that behavior 2+ years ago
<timeless> [we = Mozilla/Firefox]
ericu: if you want file saver to do the default, that's another behavior
jonas: if people only want a download mechanism, we should do it right not extend hack
arun: hack exists for http
reasons
... ericu's "uber question" is a good one
ericu: allowing all headers in seems cleaner
anne: it's complicated if we only care about content disposition
sam: setting something like x
frame options could be useful
... my recollection are that most of these things are
attributed to the resource not the url
... it seems a bit hackish to set headers on a blob
ericu: agrees. a blob might never
be used as a url
... in some cases, the headers are more assicated with the url
rather than the resource itself
jonas: this discussion has gotten
a bit meta
... should the headers arguments exist on the blob or create
url function
sam: that's one question. the other is whether we need the headers
ericu: likes headers. if we have them, put them on createURL function
anne: let's move discussion to
list
... talks about his sneaky plan
ericu: we can go back to file after writer/system questions
<timeless> the example for using URL instead of Blob to have the bits is to match Gmail where an image attachment has View and Download links - two urls to the same blob data
ericu: doesn't have any issues to bring up
anne: can you give a quick introduction?
ericu: does said introcution...
<timeless> s/cut/duct/
<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
<mjs> </sarcasm>
ericu: taking a step back....
sam: when people implement event listeners, the event they get will be a little funny because it has words like loaded
anne: inherited progress events from svg...no one backed me up
mjs: lots of bike shedding
jonas: it sucks to add aliases
sam: maybe add progress of loaded
that calls the same underlying function
... bytes progressed maybe?
jonas: just use progress
anne: we do have some aliased
properties elsewhere I guess
... let's leave "early"
anne's chairing skillz are celebrated
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/even.time/event.time/ Succeeded: s/IE9/IE8-IE9/ Succeeded: s/DOM/done/ Succeeded: s/Byorn/Björn/ Succeeded: s/swaps/mark character/ FAILED: s/Byorn Herman/Björn Höhrmann/ Succeeded: s/in general i think what's important is getting things to the REC track/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/ Succeeded: s/ons/on/ Succeeded: s/smaug_/smaug/ Succeeded: s/anne/jonas+sam/ Succeeded: s/receive headers/receive content headers/ Succeeded: s/automatic creation to simplify basic generation of/automatic creation to simplify basic generation of simpler tests to supplement hand-written tests/ Succeeded: s/public script/public-script-coord/ FAILED: s/sellenium/Selenium/ Succeeded: s/function testing/functional testing/ FAILED: s/i volunteered testing resources/i volunteer to help define the process proposal/ FAILED: s/Paulo/Pablo/ FAILED: s/Option A/pablo: Option A/ FAILED: s/@@something @@/database contains people, find person with name "foo", be that first or last name/ FAILED: s/permanent/persistent/ FAILED: s/coudl/could/ FAILED: s/doens't/doesn't/ FAILED: s/thigns/things/ FAILED: s/does it/do we/ FAILED: s/Transactions/scribe: anne/ FAILED: i/What is the current topic/scribe: anne FAILED: s/contnet/content/ FAILED: s/cut/duct/ FAILED: s/FileSaver/File: Writer and File: Systems and Directories/ FAILED: s/introcution/introduction/ FAILED: s/waht/what/ FAILED: s/picassa/Picasa/ FAILED: s/doens't/doesn't/ Found ScribeNick: MikeSmith Found Scribe: Mike_Smith Found Scribe: MikeSmith Inferring ScribeNick: MikeSmith Found ScribeNick: timeless_mbp WARNING: No scribe lines found matching ScribeNick pattern: <timeless_mbp> ... Found ScribeNick: timeless Found ScribeNick: timeless Found ScribeNick: timeless Found Scribe: MikeSmith Inferring ScribeNick: MikeSmith Found Scribe: anne Inferring ScribeNick: anne Found Scribe: jorlow Inferring ScribeNick: jorlow Scribes: Mike_Smith, MikeSmith, anne, jorlow ScribeNicks: MikeSmith, timeless_mbp, timeless, anne, jorlow Present: ArtB DougS MikeSmith Geoffrey SamW Maciej DaveR Olli Adrian EliotG LaszloG YaelA AnssiK_SureshC Dom Johnson AnneVK KlausB Wonsuk_Lee RichardT BryanS KaiH Bryan_Sullivan Jonas Pablo Jeremy Andrei BoChen DavidRogers EricU AdamB Anssi_Kostiainen Found Date: 02 Nov 2010 Guessing minutes URL: http://www.w3.org/2010/11/02-webapps-minutes.html People with action items: add barstow link xhr[End of scribe.perl diagnostic output]