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