Web Applications Working Group Teleconference

02 Nov 2009


See also: IRC log


Chaals, Sam, Per_Erik, Vladimir, Satoshi, Shiki, Arun, Nikunj, Anne, Rob, Lachlan, Jonas, Travis, Adrian, Maciej, Doug, Sicking, MikeSmith, Julian, Ishida, Addison, NorbertL, Hixie, Mike™, Felix, Marcos, Benoit
Travis, Chaals, Sam, Maciej, Nikunj, sicking, s icking, timeless, annevk




<Travis> scribe: Travis

<scribe> scribeNick: Travis

Introductions for Persons present at the WebApps TPAC Meeting

<chaals> http://www.w3.org/2008/webapps/wiki/TPAC2009APIs

Progress Events

chaals: Any additional items to add to the agenda?
... Spec has been stalled for some time...

<chaals> --> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.32 Editor's draft

chaals: Progress events are events for showing progress :-)
... Issue about what events must be defined in the spec itself.
... Justification is that there is a definate pattern that must be followed when implementing these events.
... Progress events have been implemented by SVG some years ago (there a bit of a legacy)
... Considering making the events requirement a "SHOULD" instead of a MUST.
... This text presumably makes it easier to integrate into other specs.

Hixie: Main concern with the requirements able to be defined in other specs and the progress events spec is how do you test this?

shepazu: Can progress events be implemented outside of a host language?

Hixie: Would like to have a normative section for what the event objects look like, then a non-normative section for what other spec authors should generally follow.

shepazu: Concerned that an implementer wouldn't implement the non-normative parts.

chaals: With a spec only having SHOULDs, there's no normative requirement for implementors!
... Would such an approach make sense?

Hixie: From a UA point of view, the dispatch of the events section in Progress Events would be redundant with the definition in a host spec.

chaals: Without a normative requirement, there's nothing to prevent anyone from completely ignoring the spec.

Rob: Would it make sense to have a section for reasons why the Progress events wouldn't be used as spec'd?

shepazu: Question about what the different use cases are for when scenarios might employ progress events.

<shepazu> for example, you could use progress events for computationally intensive processes

mjs: Should have a section for how Progress events should "typically" be used (in a basic scenario), but to not overconstrain the spec.

chaals: I propose to take the MUST requirements off of the UA requirements, and change these to SHOULD, and include examples of when you might not want to follow the basic pattern.

anne: Don't think it makes sense to have user agent requirements in this spec.

Hixie: There are conflicting requirements must / must not depending on the spec.

anne: XHR, AppCache, Media Elements all specify how these events are to be dispatched.
... So don't see the point of a common model.

chaals: Rather than having a new spec author search through the various specs to find the common pattern, they could go to one place (the Progress Events spec) to have a template to copy.

Hixie: Great--as long as it's not normative, I love it.

shepazu: +1

anne: Seems pretty complicated to a make a generic model.

<Hixie> specifically, what i thought i understood was that the progress events spec would have a section that can be copied and pasted into other specs, that would put requirements in those specs for queueing tasks to fire events, etc

<Hixie> these requirements would not be normative at the progress events spec level

anne: No formal objection.

<arun> If it is non-normative, issues behind objections can probably be mitigated (e.g. how complicated a general model might be).

<chaals> Proposed resolution: Remove the User agent requirements and make them informative for the "default case", provide examples of how a spec would incorporate the default case and examples of where it would do something differently

<chaals> RESOLUTION: Remove the User agent requirements and make them informative for the "default case", provide examples of how a spec would incorporate the default case and examples of where it would do something differently

<MikeSmith> Hixie, so HTML5 has no normative dependency on Progress events currently, right?

chaals: Issue 105

<weinig> http://www.w3.org/2008/webapps/track/issues/105

<Hixie> it has one for appcache

chaals: Use cases for my "email scenario" and the Media streaming events were different.
... Was my addition of the attribute for tracking different transactions useful?

Hixie: The model you describe (with sub-transactions showing progress) leads to horrific UI.

chaals: Yes, but I like that UI.

<MikeSmith> "The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that a file is being downloaded in preparation for updating the application. [PROGRESS]" http://dev.w3.org/html5/spec/offline.html#downloading-or-updating-an-application-cache

shepazu: In the multiple items case, could I make a progress bar that handled X different items downloading at once and consolidate them?

Rob: Might want to make this very simple and keep the progress as percentages only.

chaals: On percentages: this can get tricky when you don't know how much data you're going to get.

MichaelNan: In favor of simplifying the progress events.

weinig: May not need to define in the Progress Events for sub items, but leave it up to hosting specs to provide a means to define how unique progress events are tracked.

chaals: The purpose of the two extra attributes was to allow the data for sub items to be tracked.

weinig: For the non-simple cases, an informative section describing how to handle these might be easier.

Hixie: Could look to XHR's upload concept.

<anne> http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-upload-attribute

<scribe> ACTION: weinig to write up sample on what the multi-file progress informative text might look like. [recorded in http://www.w3.org/2009/11/02-webapps-minutes.html#action01]

<trackbot> Created ACTION-431 - Write up sample on what the multi-file progress informative text might look like. [on Samuel Weinig - due 2009-11-09].

chaals: Issue 107 is largely redundant if we simplify.
... There is another question: what does the total and loaded count mean?
... Now is specifies the number of bytes.
... In removing the normative requirement, the "bytes" requirement could totally go away.
... Makes sense for me to recommend bytes as the default simple case.

Hixie: So far, the various specs interpret the values different already {files, bytes, objects}

chaals: Propose we drop the total bytes in favor of showing progress of "something".

<MikeSmith> chaals, Ian Fette and Lachy came in, need to intro himself

shepazu: Please keep existing text in place for a compare/contrast draft.

chaals: I think this wraps up what I had to discuss on Progress Events.
... Let's break now, and reconvene at 11. We'll be in Salon 5 meeting with Device API.

<chaals> Scribe: Chaals

<scribe> ScribeNick: chaals


AvK: Two open issues raised by mnot
... one is naming, one is technical. And a missing issue MM is here to talk about - should we throw it all away...

MM: Suggesting the mechanism should not present authorising information in a ?? fashion. It's up to applications to decide what to do

AvK: Also status of origins spec at IETF, and call for tutorials/use cases.
... let's begin with the big fat guy in the middle of the room

MM: Objection is that we know about confused deputy problems. Systems that do authentication by associating authority on the identity of the requesting identity creates vulnerabilities.
... CORS links origin of requester from origin header, which fulfils requirements to make Confused Deputy problems.
... discussion hasn't addressed the objection.
... Not showed that it doesn't apply, doesn't matter, etc.

AR: Can anyone show a sample attack that demonstrates the nature of the problem?

MM: Tyler Close posted a 3-aparty interaction where each step is intuitive in CORS< and the result creates a confused deputy problem.

MJS: My reply was that this came from using arbitrary URIs rather than recognising that they are meant to be scoped to a specific subdomain. Don't think that is created by CORS

MM: What validation should the second party do to the URIs to ensure control?

MJS: Site 1 has photos, site 2 printing, site 3 has storage.
... photo site wants printer to get things from storage.

<Hixie> http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1324.html is Tyler's example

<anne> example from Tyler: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1324.html

MJS: etc.
... Right approach: Printing site creates one-time store, passes that, and the photo site uses a different API to pass it to the photo site.

TC: That is right, but you don't need CORS to do it

MJS: How do you do it without server-server comms which is a goal of CORS

<ht> ArtB -- TAG is coming, unless you say no. . .

<MikeSmith> chaals, some TAG members will be joining in a minute

<arun> This is Tyler's Email: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1324.html

TC: We know in principle that using client authentication is vulnerable to CD. We have experienced this on the web - csrf, clickjacking.
... CORS proposes another way to use client auth on the web.

DS: It seemed that the attacks are not malicious, but accidental. Ambient authority gets wrong access.

MM: My sense was that it is not accidental. The program issuing a command could, I think maliciously, "mis"direct information

DS: Think we could distinguish accidental cases (things people get wrong) from malicious attacks - the latter are ways people can hack you, the other is something that doesn't give malicious access.

MJS: CSRF lets people set up malicious attack

MM: I am happy that if we can solve the malicious cases we are fine.

TC explains his email example with a drawing.

<shepazu> original confused deputy description: http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html

MJS: I think that this setup requires a shared secret, which requires server-server communication.

TC: 3 servers. 1 has photos, 2 is a printer, 3 is a storage service

MJS: CORS tries to cut out the requirement that your servers have to talk to each other in order to allow the request. Request something from server A, then you can make a request to server B without having to ping back to server A and ask that to talk to B

<MikeSmith> somebody who has a camera should please take a photo of Tyler's diagram

TC: I think you are explaning how people can use one-time tokens to solve that problem. We don't think you need to use CORS to do that, and if you do rely on CORS you are vulnerable to Confused Deputy

<DanC> (what mjs said sounds like one of the CORS requirements... advancing the state-of-the-art from having to go thru the origin to get to (coorperating) 3rd parties)

MM: The key is that post-login the auth login is not ambient

MJS: Main reason for CORS is to bootstrap the one-time mechanism - only other known way are shared secret on server side and require server-server communication to pass the tokens
... (server can't send its secret via the client, because then it isn't secret)

DS: Is the data otherwise secure?

TC: Yes.

<DanC> (can't quite tell if that requirement is in http://www.w3.org/TR/access-control/#requirements or not. maybe it's in the use cases.)

Rob: Seems there are disagreements on what CORS is. You see it as an auth system, and I don't think that it is - CORS says you can talk to this guy, but the auth sits on top of that.

MM: You are not an origin...

MJS: You can make a request, but you can't guarantee that it gets fulfilled

TC: CORS adds a header on origin, that sites will use (because they are encouraged to) as a mechanism for auth, and that leads them to be caught by confused deputy

<DanC> (the security risks are clear enough to me; have alternative designs that avoid the risks been offered?)

MJS: Think that there are cases where CORS will be used, that do not introduce the problem. I want to see why we will run into problems.

MM: Objection specifically applies to 3-party scenarios. 2-parties don't create a problem. But once you create the system, and people apply their 2-party system to 3-party cases, you *will* end up with problems.

MJS: Classic CSRF problem is that the 2 parties are a site expecting a form, and the user giving it, and a 3rd-party making malicious use of the user's authority.

<DanC> (seems to me all the relevant arguments are represented in the WG; if you just give me an issue # so I can tune in later and see what's decided, I'll happily go do other stuff.)

<ht> +1

<anne> DanC, there is no issue number

<DanC> yeah, that seems like a bug

MJS: CORS lets you solve this by giving a secure mechanism for dealing with the transaction.

<DanC> easy to fix: ISSUE: confused deputy problem

<anne> DanC, if we agree this is an issue there's no need for an issue number because we'd need to do something else

TC: Web browser is on a site that cmes from the photo manager. all interactions take place on that page.

<DanC> anne, not at all.

<noahm> Art: I'm seeing some sentiment that if the Webapps group would open a formal issue to explore confused deputy, the TAG would consider that a good step.

TC: user hits a button to print a photo. a button asks a printer site to print a photo.

<DanC> an issue is just a promise to make a decision; it doesn't presume which way the decision will go

<scribe> ACTION: chaals to raise an issue for this question [recorded in http://www.w3.org/2009/11/02-webapps-minutes.html#action02]

<trackbot> Created ACTION-432 - Raise an issue for this question [on Charles McCathieNevile - due 2009-11-09].

<MikeSmith> action-432?

<trackbot> ACTION-432 -- Charles McCathieNevile to raise an issue for this question -- due 2009-11-09 -- OPEN

<trackbot> http://www.w3.org/2008/webapps/track/actions/432

<anne> DanC, fair enough http://www.w3.org/2008/webapps/track/issues/108

<anne> close ACTION-432

<trackbot> ACTION-432 Raise an issue for this question closed

<DanC> :) issue-108. thanks.

<MikeSmith> ht, I will change that now

IH: How does the manager authorise printing?

<ht> 2..

TC: Out of band, they made an agreement that the manager could ship jobs to the printer.

MJS: THe question is whether there is a sensible way to use CORS that doesn't have a vulnerability?

CMN: I think the question is whether there is an obvious way to use CORS that introduces a security risk

TC: We are objecting to the idea that the group is baking up a way that people will create security risks

MJS: I don't think that is an issue. CORS allows for 2-party transactions to be done that are secure.

MM: The 2-site model is OK. The problem is that the assumption that the request reflects only the requestor's intention, and it is actually formed using information coming from a third party, a set of decision each individually sensible will compose to create a 3-party interaction pattern that we know to be vulnerable.

TC: You say it is unlikely, but we have seen it played out into cookies. and into clickjacking. How often do we repeat the pattern before we stop doing it?

[back to the example]

<MikeSmith> issue-108?

<trackbot> ISSUE-108 -- confused deputy problem -- RAISED

<trackbot> http://www.w3.org/2008/webapps/track/issues/108

TC: The page now sends a request to the printer page to get the spool file, then we send a request to the storage page to copy stuff into the printer spool.
... the user owns lots of sites on the storage site. If the printer site sends back a request for DontTouchMe, the file transferred goes into DontTouchMe instead of a spool file.

MM: Intuitive assumption for the developer is that the URL from teh printer site is a URLthe printer has access to.
... problem arises because if the storage site checks access against the origin, it will check against the manager's access, not the printer's.
... manager would want to make the decision based on whether the printer has access, but has no way to ask that.

TC: There is an access control problem. CORS is telling developers to use a solution that won't work. There are other solutions.

Rob: If manager was only talking direct to the client, direct to the printer, and direct to the store, no problem.

AR: The use case can be shoe-horned into other systems.

MM: Yes, into any situtation where auth is passed on behalf of the client. If the requestor can say "I want this if my request source had access" then you solve the problem.

DS: MM agreed there are ways to build secure applications with CORS< as well as building vulnerabilities.

MM: True.

<mjs> oh hey Zakim is back

MM: Issue is primitives that compose data. Analogy - LISP was dynamically scoped, and that was useful in many ways. But there were a set of individual decisions where you can't know tha they are bad, compose together to create a problem.

CMN: If you can restrict the system to 2 servers, can you avoid the problem.

TC: No. You can still make the problem without the 3rd website.
... e.g. combine the storage and manager here

IH: Why would the manager give the printer access to tell it to write something over closed content?

MJS: it seems in the 2-party case you have to make it needlessly complicated to make the vulnerability work

TC: If any auth data from site A came from site B, you create confused authority.

MM: If you are not using anything that didn't come from *you*, then you are not creating a vulnerability.

TC: If you can say "don't apply my authority to anything I didn't make myself" you solve the problem.

MJS: If making requests to yourself can have this problem, that already exists. XHR requests to you implicitly carry auth because you are the only one that can make a request to yourself.
... so any request using info from a 3rd party exposes this.

TC: Yes

MJS: Self to self has client authority

TC: Yes, but we should be trying to reduce this.

MM: Guest XHR should not present auth even when it goes back to its own origin.

MJS: So using guestXHR is similar to formulating requests in a way that you use guestXHR-like behaviour for requesting things with 3rd party data.

MM: Yes. It is normally possible to make the mistake. Compat prevents us from retiring existing mechanisms that allow this, but not introduce new mechanisms that have the same problem, but a new mechanism that doesn't have this problem.
... guestXHR is a refolrmulation of CORS that addresses our security concerns.

<timeless> a/folrm/form/

JS: Do you have an alternate proposal. If GuestXHR is it, how do you build a website that uses it nicely?
... imagine websites would be hesitant to ask users to copy strings from one place to another

TC: A lot of them are possible that look pretty much like existing things. There are existing UIs that are inherently vulnerable to clickjacking, but we could use others which are not vulnerable.

MJS: Think the 2-site mechanism is the thing we are interested in.

TC: Would like to see the problem being laid out for existing approach, and I will explain how to fix it

<scribe> ACTION: jonas write a very concrete example of a problem [recorded in http://www.w3.org/2009/11/02-webapps-minutes.html#action03]

<trackbot> Created ACTION-433 - Write a very concrete example of a problem [on Jonas Sicking - due 2009-11-09].

<scribe> ACTION: Tyler to explain how to do it with guestXHR in a nice UI [recorded in http://www.w3.org/2009/11/02-webapps-minutes.html#action04]

<trackbot> Sorry, couldn't find user - Tyler

<ArtB> mjs' example: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0350.html

Rob: Fundamental problem is if manager can be asked to do something by another party, with the authority of the user in the middle.
... question is whether CORS encourages that behaviour


<tlr> +1 to "are people encouraged" as the key question

scribe: I am not convinced we are encouraging this behavious with CORS. Are we making it any more likely?

<timeless> s/vous/vour/

MM: Problem is not encouraging lack of checking, problem is creating a demand for checking that cannot actually be met.
... if authority is carried along then there is no problem.
... Existence of CORS doesn't force servers to make decisions based on origin. If servers make the decision based on extra information carried alongside.

Rob: CORS doesn't create the vulnerability, it creates a communication path.

MM: Creates an conditional path. if it were unconditional there wouldn't be a problem.

AvK: It needs to be conditional

MM: And therefore it is inherently an access control problem.

AR: zakim, close the queue
... You have shown a model where Confused Deputy can be createed. I think there are clear scenarios shown where it cannot be a problem. There are use cases CORS addresses that solve badnesses people used in the past.
... there is some case to draw these examples and explain them as bad design.

TC: Yes. Ditto HTTP auth, but we saw people actually used it in a way that led to problems, and we suspect that CORS will be used widely to produce such problems.

DS: Let's say we keep it as is, and describe carefully how it should not be used and explain the problems.
... nobody wants to create insecure interfaces. Can we show them why not to do A, and why to do B instead, would that work?

MM: yes...
... point is to enable people to write applications that are useful and secure, and that requires education, any solution we have will require that.
... The question is not whether you can make things secure, the question is whether you can modularise sensible decisions and then compose them to make problems, you have created a fail.

DS: There are inherent composition problems. Can we forestall those in practice?

<mjs> awww

MM: If the token is passed along with the request, and origin is only used for forensics (logging who asked for what) then you don't have a problem because access came from the right token, and you have forensics to find out where bad requests are coming from, you are reacting to having allowed inappropriate access, and then CD is lesser evil.

TLR: Hear the argument a lot that X is a bad application design decision - and that is true. Often they are poor decisions under composition. THinking through, what kind of services will use CORS? We will see relatively generic services - data bus, message bus, etc. These may well permit access to other apps, based on a mix of CORS and maybe others. And those sound like things that will get composed and therefore lead to composition problems.
... market isn't just working in tight coordination, but people making building block services, we get into scary teritory. And I am starting to be convinced by Mark and Tyler's argument - I think we need to be really careful of it.

CMN: We will wrap here, because we are not getting to resolution
... will look for more time to do this tomorrow

DS: Can people try to prepare clear presentations for tomorrow?

AvK: Would be good if they can be very concrete.

MM: Didn't see in the draft that a requirement is to avoid server-server communication... is that an understood requirement?

AvK: Yes...

<scribe> Scribe: Sam


<scribe> ScribeNick: weinig

anne: there are a bunch of spec that refer to views
... rendered view/default view
... in reality, all implementations always return the default views
... we should kill the concept of views

shepazu: inventor of views thinks it was a bad idea

jonas: mozilla has support but it is a pain in the buttox

shepazu: does anyone know of any implementations

jonas: mozilla uses if for print preview, but it is not accessible from the dom

maciej: concept of views seems unnecessary, but there APIs we need to keep (AbstractView, etc)
... getComputedStyle

anne: we should keep the APIs, but get rid of the concept
... offsetLeft, etc, will all be relative to the one true view now

shepazu: I agree completely

<chaals> [discussion of details about which specs and how we organise them]

maciej: UI events need a view

RESOLUTION: Remove concept of views

MikeSmith: what about DOM Level 2?

chaals: we should issue an erratum

Paul: we can issue a note on the existing spec
... for the TR page

chaals: we want to point out that there is an "untruth" in the DOM Level 2 spec which people are reading

<chaals> SW: I implemented some stuff in CSSOM for fun, and we found that CaretRangefROMPoint is less useful than we would like

<chaals> ... one of the constraints is that it is only over what would be editable. For areas that look/are selectable, they don't necessarily have a DOM range.

<chaals> ... Use case was dictionary popup - want to know what word you are over.

<chaals> DS: Ditto in IMEs

<chaals> AvK: Maciej proposed to change to CaretPositionFrom Point, which is an offset integer from the current node (number of characters...)

maciej: in the case where the parent is an element, it can be an awkward API


<timeless> ACTION: ArtB to notify Widgets WG that they have 2 weeks to review WARP [recorded in http://www.w3.org/2009/11/02-webapps-minutes.html#action05]

<trackbot> Created ACTION-434 - Notify Widgets WG that they have 2 weeks to review WARP [on Arthur Barstow - due 2009-11-09].

maciej: there is no way to know all the of the names of the form controls

tl: can css change things into form controls

maciej: there is css-appearance
... there is svg:textarea

anne: that has ranges inside it if is editable

maciej: 3 cases, 1) if you hit a text node: the containing node is the text node, the offset is the offset into the text node
... 2) if you hit a form control, the container is the control, the offset is the offset in the control

<chaals> SW: With range ability to get position you can get a bounding box of the collapsed range

maciej: 3) if you hit an element, you get the element as the container, the offset is the range offset

anne: the caretPosition object should have a range attribute, which is null for form controls

<chaals> SW: do we want to make stuff aware of CSS transforms, or add a new set of APIs that return quads based on 2d transforms except giving quads?

anne: dean (apple) asked me about that, people from apple have been asking me about it as well

maciej: returning the bounding box seems like the most sensible thing

anne: that is what is done for svg

maciej: but we should have quad apis as well
... maybe we only need 3 points, maybe we want 4 for perspective transforms
... math is hard
... all we really need is a way to take the bounding box and convert it page space

<anne> http://www.w3.org/TR/2009/WD-css3-2d-transforms-20090320/#dom-interfaces

maciej: we need a way to convert a point from node to page space (and vice-versa) as well

anne: what is the coordinate system of the node

chaals: it is the point in the transformed node

chaals does something with his hands

anne: we should probably try and move these apis away from the window if we can

<chaals> Proposed RESOLUTION: Anne will (get help from some clever guy at Apple to) spec up the ability to get the bounding box, under transformations, and the bounding box of the transformed quad within the page

<chaals> RESOLUTION: Anne will (get help from some clever guy at Apple to) spec up the ability to get the bounding box, under transformations, and the bounding box of the transformed quad within the page

<chaals> in recess

in recess

<chaals> Scribe: Maciej

<mjs> avk: ISSUE-33 - should re-entrance be allowed for readystatechange

<chaals> ScribeNick: mjs


js: so are you not allowed to call open? does that throw an exception?

avk: in IE yes

<shepazu> trackbot, start telcon

<trackbot> Date: 02 November 2009

<shepazu> ISSUE-33?

<trackbot> ISSUE-33 -- Shoulld re-entrance be allowed foronreadystatechange? -- OPEN

<trackbot> http://www.w3.org/2008/webapps/track/issues/33

tl: if you open from a readystatechange handler on the same object?

js: yes:

tl: I don't know what IE does

avk: other browsers allow it, and restricting it would be weird

tl; sounds like it's a synchronous event allowing re-entrancy

js: my recollection is it was more a concern with later readystates like 3 or 4
... I know we just allow anything anywhere, I don't remember what IE does

<scribe> ACTION: travis To research what IE does for readystate re-entry (for ISSUE-33) [recorded in http://www.w3.org/2009/11/02-webapps-minutes.html#action06]

<trackbot> Created ACTION-436 - Research what IE does for readystate re-entry (for ISSUE-33) [on Travis Leithead - due 2009-11-10].

sw: I think readystatechange is async

js: not always

avk: (explains details)



<trackbot> ISSUE-103 -- accessing status/statusText/getResponseHeader()/getAllResponseHeaders() -- RAISED

<trackbot> http://www.w3.org/2008/webapps/track/issues/103

avk: the issue is that IE throws when certain methods are called in a particular state
... not throwing is generally better

tl: unless there's a really good reason to throw

js: it appears Firefox never throws for status but it might throw more often for statusText
... appears to throw a random number

sw: we added throwing to match other browsers (the minimum)

js: why did you change, was it b/c websites complained?

sw: I don't remember, it might have been to change the spec

*general mumbling*

*awkward silence*


avk: what are we going to do - change and not throw?

js: I'd like to err on the side of not throwing

RESOLUTION: for ISSUE-103, don't throw

the other bit for XHR1 was the test suite

^ avk:

avk: it would be nice to have some help at some point

fo: I've got some notes which I still owe you on that

jr: do you have mark nottingham's tests? do they cover different things?

avk: probably

jr: I think he's got things checking caching

avk: the test suite has quite a lot of coverage, especially security stuff and resolving URLs
... there's definitely more things that can be tested

cmn: which things are those

avk: methods probably... http verbs
... there's a bunch of side effects that are not all covered yet, e.g. when you invoke open()
... *more technobabble about complicated steps*
... I don't think there's tests for Accept, Accept-Language, conditional GET

mjs: are the tests in cvs?

<anne> http://tc.labs.opera.com/apis/XMLHttpRequest/

avk: not currently

<anne> http://tc.labs.opera.com/svn/

avk: I don't really like working on tests

ds: Anne, what's your job title?

avk: I work on specs!

cmn: any volunteers to write tests?

<scribe> Scribe: Nikunj

avk: Starting on XHR2


Issue 104?

No serialization defined for structured clones

avk: Use multi-part MIME for structured clones

avk may be JSON support at some time

<sicking> ISSUE-104?

<trackbot> ISSUE-104 -- supporting structured clones -- RAISED

<trackbot> http://www.w3.org/2008/webapps/track/issues/104

avk: Close 104 for now and revisit when we have a serialization format
... structured clones can include certain data types beyond JSON
... such as images and files

mw: used for local storage, and others

avk: used also in post message
... waiting until file API to add file upload
... also waiting to append file blobs
... browser would send multipart form-data when you do send
... similar to raw html forms no
... if we can support this API then we don't need a FileList in the API
... could be Jeremy Orlow
... append files or strings on formdata object

so that we don't need a method on XHR

avk: its been requested to serialize an html form and pass it to XHR
... so you can asynchronously upload it
... others requested - blob
... WebKit supports FileList

ar: File is supported in Mozilla

sw: WebKit also supports a single File

jonas: do you send the file name anywhere?

avk: no

sw: no

avk: how would you?

jonas: use some kind of header

avk: authors can add a headers

sw: we don't

arun: send a blob and a hypothetical object

avk: send would be extended to accept Blob and FormData

<arun> where FormData = hypothetical object

avk: For FormData, the UA would set the content-type header if the author did not set it

arun: Is Hixie writing FormData?

avk: No I will do it - a small edit

arun: FormData append would accept a Blob?

avk: It would
... It seems that this would address several requests

arun: It seems to - a requirement that was not adequately addressed by FileAPI

avk: MS has a proprietary extension exposed to VBScript called ResponseBody that returns a byte array or byte stream
... we could use it or rename it to ResponseBlob
... Unless MS cares for it

adrian: we would like to carry on using it

mjs: It should not be a blob, but rather a byte array
... Blob offers only async, and if the data is already loaded then array is better
... should not do another async

jonas: only thing is if you are loading a big thing, then ua will be forced to keep it in memory

mjs: if loading something bigger than address space, then store it

jonas: not looking for large streams

mjs: ideally ua should download large files through streaming model
... assuming its a file object stream to a file

avk: and then access the file
... responseText already loads in to memory

mjs: turn off storing in memory if its large

avk: need ECMA to figure out a binary type array
... should not be that hard - like image data

mjs: easy to make complicated
... if its immutable, then it is easy to use the raw bytes as backing store
... no thread safety issue even if passed to workers
... immutable is harder to modify
... most APIs make two versions of APIs available - mutable and not

avk: ImageData is immutable

mjs: backing store is canvas

jonas: byte array building API might be a good way to mutate ResponseBlob
... look forward to mjs' proposal

avk: response thing and new things for sending out are new items
... timeout proposal is also new
... ontimeout listener for milliseconds timeout
... if the server doesn't respond, then do the abort thing and dispatch timeout event
... timeout needs to be sorted out

jonas: two arguments - sync XHR doesn't allow timeout
... not allowing timeout doesn't preclude users from using it

avk: use workers

jonas: provide timeouts so that user experience is slightly better

avk: are you providing them?

jonas: yes

avk: timeouts are something that you should certainly have

jonas: almost everyone using XHR uses it anyway, so provide a convenience function
... MS added it to XDR?

adrian: yes

sam: is it a default or an attribute?

adrian: attribute

avk: what does it do on getting?

jonas: its a set only

avk: does such a thing exist?

travis: doing a quick test

jonas: what's a good default value

travis: or do you timeout at all

adrian: if not set, it doesn't
... so the behavior is not changed
... XHR also has the like named attribute

jonas: very inclined to add the attribute to XHR2 spec

sam: concern - putting in the hands of the user, what is the stall for the ua?
... 10 ms is OK or 100 is OK?
... in the past any amount was OK

<Travis> Reading IE's timeout property (before setting) returns -1.

avk: testing in different conditions, like a slow network, may find odd behavior but the other person in a good one doesn't

adrian: common use cases are sites doing click tracking, trying to capture when someone clicked a link
... OK with losing data when a request is not fired in the timeout
... here's a request to make and if the request doesn't respond we give up

avk: better option available - html5 ping attribute

adrian: there are other issues being raised, that make the option controversial and this WG is not the right forum to discuss

avk: not opposed to adding it, concerned that it will be abused

jonas: in what way?

avk: use sync more

jonas: what will help most is a test suite guide
... go through the spec and not follow it closely, although well followed,
... edge cases are where we differ, otherwise everyone is close

avk: but that makes it look pretty broken

jonas: not material adding new features to newer versions to getting bugs fixed

avk: explicit constructor for XO requests

jonas: that conversation is sort of CORS-existential one

avk: agreed

jonas: interesting idea to have a totally anonymous XHR object, both for X-S and S-S request

travis: which is XDR

jonas: but that sends Origin

avk: proposed resolution on timeouts for XHR2
... to add

nikunj: would we do it to file?

jonas: not required to follow a single style in general
... hesitant to draw a connection?

adrian: a case to be made for XHR things to be repeated elsewhere
... timeout is not one of those things
... network requests cause timeouts to matter
... it seems less likely to need them for files

jonas: much less likely for a file request to time out

sam: network files time out

adrian: edge case

avk: also need resolution on FormData

jonas: iffy about that
... seems weird to create a new object for creating an object only to send to another one

avk: not ugly, can reuse it

sam: websockets may also want to do it

jonas: really?

everyone: laughing loud

chaals: consensus?

sam: I don't object, not excited

jonas: it helps to abort a connection if it takes too long

sam: agreed, but not a strong enough reason because that might be only one of the ways to do it

jonas: could use setTimeout
... risk that people may use sync XHR more
... we fired timeouts during syncXHR
... fallback was to wait longer
... not ideal
... some people may never switch away from sync XHR?

adrian: we shipped timeouts
... good idea

chaals: any objections?

sam: risks in either direction

adrian: also supported for sync XHR

RESOLUTION: Anne to put timeout attribute in XHR

avk: Proposal to overload send for Blob objects
... FormData contains a constructor and accepts either Blob or DOMString

which serializes as multipart/form-data

sam: support strongly Send Blob with File
... other one need to see a proposal and remove it if that looks terrible

jonas: feels same way

<anne> http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0244.html

RESOLUTION: Copy and paste this into the proposal on FormData and Blobs

jonas: like to implement streaming
... loading something means you are adding something constantly to the DOMString, using exponential memory. Having some way where you can store data to the file object or a way to erase the differential read since last event. Impl can throw the rest of the data away

avk: can we use server sent events?

jonas: this is not for that, but for large files
... its started from server sent events, but different

avk: use cases are required

chaals: good proposal not quite a finished
... need a meatier proposal

jonas: would do

chaals: how far from XHR?

avk: ask jonas, sam, and adrian
... if everyone finishes implementation, then we are done

jonas: start writing test cases

adrian: take it first to LC, then the test suites will happen before CR

avk: ISSUE-33 needs to be resolved first

travis: it is already re-entrant

chaals: so we can close the issue?

jonas: can we go to LC?

chaals: we need a formal vote

avk: need to edit the spec first

RESOLUTION: Close ISSUE-33 because everyone is re-entrant

chaals: should we take anne's draft to LC?

avk: this is the third LC

chaals: RESOLUTION: XHR goes to Last Call
... meeting is adjourned

<sicking> scribe:sicking

<scribe> scribe:s icking

<scribe> scribe: sicking

<weinig> [The spec we will discussing is available at http://dev.w3.org/2006/webapi/WebIDL/]

WebIDL yo

AR: Arun

SW: introduction about webidl

<weinig> http://dev.w3.org/2006/webapi/WebIDL/

AR: there's some things that are still left loose, we should define those stricter

SW: ok, got specific issues?

AR: how are exceptions done?
... missing primitives like ByteArray

SW: have to check spec re exceptions
... re bytearray, it's a question of scope
... spec already big. Contains gramar, some basic primitives like getters/setters/stringifyers, also some types and extended attributes
... sequences would be useful

JS: need to define what exactly a seqnece is

SW: sequence is a JS array, array is a host object

<weinig> http://dev.w3.org/2006/webapi/WebIDL/#es-sequence

SW: NodeList seems to map closer to array

JS: NodeList is readonly, so can't be a simple JS-array

NM: is anyone actually using Array?
... crickets...

SW: don't know of any specs that use it. Maybe NodeList could be expressed as an Array
... might not be worth putting Array in v1 if no one is using it

<annevk> hmm, I think sequence<> needs to map to an object that has item() and length; is that the case?

TL: TC-39 is taking interest

<annevk> well, it would be nice to have a shorthand for NodeList like interfaces

<annevk> not sure if it needs to be sequence<>

TL: I expressed it to them as an grammar language, and a binding language
... they took a lot interest in the binding part
... TC-39 expressed interest in owning the JS bindings, claiming they had more expertize

SW: I think the main value of webidl is the bindings, not so much the grammar

TL: agreed

AvK: also value for spec authors

SW: concerned about splitting out bindings

TL: then they should be able to participate

SW: most definitely

DS: I'm also concerned about splitting it. Splitting things in two leads to overhead and poor coordination... I would be happy to have it worked on jointly, if we can do that, and public-script-coord should help

SW: there are things we could split, like deprecated features

annevk, that's how I roll

MJS: even such a split is concerning. Similar to how ecmascript leaves host objects largely undefined

SW: agreed

MJS: explicitly noting that certain things are deprecated could still be done

TL: do we know what we want to mark as deprecated

SW: custom deleters

MJS: also catch-alls in general
... not neccesarily consencus that catchalls are always bad
... separately, seems to be consensus that array-like accessors are ok

AvK: what does "deprecated" even mean?

SW: that a feature shouldn't be used in new interfaces, but is described for legacy reasons

MJS: multiple inheritance might not be needed by existing browsers
... however SVG uses it
... browsers don't seem to implement SVGs stuff as real multiple inheritance. Simply implemented as separate interfaces

TL: there is a desire from TC-39: don't allow bindings to do things that aren't allowed by ecmascript itself
... want to be able to implement DOM in ecmascript

MJS: if you look at it as a two-sided converging then it makes sense. I.e. add features to ES to allow it to do more, and deprecate features from webidl that ES can't do

TL: want to mark things that will *never* be part of ES as deprecated

SW: how to we determine what will never be part of ES?

MJS: It's very hard. Not even catchalls are for sure never going to be a part of ES

CM: guessing the future is hard

DS: when do we expect webidl to progress to LC and beyond
... and all those other fuzzy W3C rules

SW: depends on what people want from spec
... it's really a tool for spec authors

MJS: changing the spec to use ES5 formalisms is a big change

TL: ES5 has accessors, rewriting to use those will take work

DS: Robin wanted to publish sooner rather than later

MJS: there's tradeoffs, there's many specs that want to use it

SW: I'm not all that familiar with W3C rules quite yet

DS: This is an unusual spec
... the implementations for this spec are other specs

SW: Also testcases. You can produce a lot of tests based only on the idl
... Want a tool that given an idl produces tests
... browsers are also implementors

DS: sort of circular dependency. Won't know that things worked until another spec has used webidl and that spec got implemented

MJS: we could take a stable spec, such as DOM Core, and express it using webidl

DS: Cameron did that

SW: would come close, but doesn't test everything. Might also want to do for example canvas to test overloading

MJS: should start with dom core and see what coverage that gets us. But yes, canvas would cover a lot of nice things

RE: has anyone does a matematical analysis of webidl? Would that be useful?

SW: don't know. If anyone has done it, cameron has, he loves math. But don't think he has
... OMG doesn't define enough things. That's why specs had bindings sections. But even those aren't enough, and might not be normative
... changing spec to use ES5 terminology will be a big change, but not a functional change

NM: is it a requirement for going to last call

AvK: doesn't make sense to define things in terms of ES3 if everyone implements ES5

DS: when you make that change, document how you map old terminology to ES5 terminology

SW: good idea
... not sure about some features in the spec. One is method overloading

<weinig> http://dev.w3.org/2006/webapi/WebIDL/#idl-overloading

TL: hard to have an opinion, cause it's hard to understapnd spec

SW: that's part of the problem

AvK: canvas and XHR uses overloading, though in different ways

TL: we have default values for optional arguments
... we use it for XHR

SW: when i started on webkit, we had hand-written code that implemented the bindings. We still have a custom IDL

MJS: we currently have one-offs for all overloads. Would like to use webidl to express and implement it instead

JS: not sure we can use idl with overloads directly

MJS: you can use whatever solution you're currently using
... webidl has optional. Limited by that each argument is optional. Can't enforce that either 0 or 2 arguments are provided
... if optional could be in batches, then you could require that the other arguments must differ in type

JS: errors seem to be ambigious

MJS: one problem is that anything that takes a string essentially accepts anything since anything can be converted to string

VK: one problem is a function that takes a two ints, or an int and a string. If called with just one int what do you do?

TL: i think action should be to clarify the spec and then we can discuss what we want behavior to be

MJS: in theory you can let the function just take a bunch of optional "any" arguments, and describe in prose what's required. However that's likely more confusing for everyone

JS: I think TC-39 will have strong opinions on this. I know mark miller did

MJS: not sure i understand MMs objection
... one issue is that overloads allows overloads to be added in [supplemental] interfaces. Would not match ES5 implementations

SW: we could forbid overloading in supplementals
... discussions about XHR...
... if we're gonna do union types then we should consider what tradeoffs we'd making. I.e. which group are we helping at the cost of another group
... i'd also like to know how you reference one of the specific overloads

TL: philosophical argument. Do you think of it as a single function that can take different things, or is it separate functions that happen to have the same name
... problem is that we have a spec that's hard to understand. Using union types might make it easier for people to understand it

CM: would like to wrap up

darobin, no union types for you!

SW: we need to figure out replaceable

TL: I'm also concerned about mixin's
... TC-39 would like to deprecate callable objects

JS: gecko only has a single object that's callable, the document.all object

SW: would like to remove getters/setters without name

TL: remove it

MJS: from javascripts point of view it doesn't have a behavioural difference

CM: proposed resolution: nuke it

DS: remove it but put a note that you did so, so that people can whine

RESOLUTION: remove unnamed getters/setters

<Travis> ACTION: weinig to clarify method overloading section and make it readable [recorded in http://www.w3.org/2009/11/02-webapps-minutes.html#action07]

<trackbot> Created ACTION-439 - Clarify method overloading section and make it readable [on Samuel Weinig - due 2009-11-10].

SW: not sure if supplemental should be an extended attribute or some other type of syntax. Should take it later due to out of time

TL: I don't care

<chaals> 史紀:should be core

SO: i'd prefer a separate syntax

hands off my scribing!

SW: who volunteers to fish out and expand on heycam's DOM L2 based tests?

<MikeSmith> s/じき/史紀

JS: I'll do the DOM 2 ones

SO: I'll do C++ tests

<Lachy> http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0338.html


<Lachy> http://dev.w3.org/2006/webapi/selectors-api/#nodeselector

LH: i need to finish up test suite
... spec is ready for CR, can do tests in parallel

TL: namespace resolvers still out?

LH: yes, may potentially be in selectors L2

<Lachy> http://dev.w3.org/2006/webapi/selectors-api2/


DOM 3 Events

<Hixie> omw

<mjs> won't be there (but thanks)

<scribe> Scribe: Sicking

DS: suggestion to make key values, instead of being "U+1234", to be "\u1234". I.e. be the actual character

<shepazu> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#js-escape

AP: this results in a surrugate pair being the value
... this problem didn't exist with the old "U+1234" syntax

JS: is this a problem?

AP: it means to get the actual character value you might need to decode the surrogate pair

(i follow standards)

AP: there are lots of surrogate characters
... and more with time

DS: maciej wasn't sure that there are keys that result in a non BMP character
... however there appears there are
... characters "tree stub" and "untidy" are such characters

<mjs> my old suggestion of "\u1234" was meant to suggest the values should be a string of the actual character

<mjs> so for example the identifier when you press lowercase a would be the string "a"

IH: for people that compare with a string, then the fact that it's a surrogate pair then this isn't a problem

DS: complicated in some situations

IH: when?

DS: when people use lots of supplementary characters in the script. Maybe

JS: can someone show code that they are concerned about won't work
... confusion about what is actually suggested...

<chaals> [Do you get "U+1234" or "æ" or "\u1234" and is there any reason to distinguish the second and third cases?]

<chaals> Scribe: chaals

RI: You take a character outside BMP, and your javascript escape is "\1234\5678"

PA: The string that is the individual character is length 2

<sicking> RI: why move away from the "U+1234" format?

<sicking> DS: if i'm trying to limit a form to just one character, i might reject surrogate pair characters

Sicking: We should go with the native format for the language. Unfortunately javascript has a nasty way of dealing with characters outside the BMP. If we give them in other forms tey will just convert and then go on anyway. SO trying to work around the behaviour of the language will frustrate people

<inserted> scribenick: sicking

JS: my concern is that we're trying to work around behavior in ES

AP: i just want people to know what the ramifications are, and that we make it clear in spec

RE: when pressing "e", i'll get an "e", but if I press "treestub", i'll get "U+1234". That seems to make i18n harder

RE: for keys like "F1" we can use a different field

AvK: the way javascript deals with i18n should be an orthogonal issue

AP: we should follow the way that javascript deals with i18n
... even if that isn't perfect

RI: i want to know how this is expected to be used
... if you just want a label for what was pressed then "U+1234" syntax seems better
... so trying to understand what the use cases and expected uses are

DS: comparisons often

<chaals> JS: If the characters are described as double-escaped bytes, you can still do comparison with them

<Hixie> '\uFFFF' < '\u10FFF' => false

<chaals> JS: Does any use case run up against that painful gap in practice?

DS: range checks might also be common

TL: in all the cases we describe now it seems workable to use the current proposal (i.e. the "treestub" proposal rather than "U+1234"). Would it be ok to go forward with that and describe how to do the various use cases

<chaals> IH: I think we are fine because I don't think we will meet the boundary case

IH: in fact, the "U+1234" syntax compares even worse for range checks

AvK: I don't think we should try to work around ES problems

AP: you can maintain that ES is broken. But what you're doing is developing a key events spec. I don't see a problem with returning the character that was pressed.
... if you tie yourself to UTF16, then that could be a problem.

AI: if i have a ascii page, how would i use this

AvK: the spec would simply say, U+1234, without quotes
... that's what other specs do

DS: i was confused, but now i can see

IH: WebIDL will handle it

DS: will that be clear for authors

IH: should have a separate section that describes things for authors. You probably want that anyway

RESOLUTION: The return value will be a DOMstring which is the character produced. We add a note explaining to authors what happens

<shepazu> ACTION: shepazu to add clarification for authors of JS where the gotchas are [recorded in http://www.w3.org/2009/11/02-webapps-minutes.html#action08]

<trackbot> Created ACTION-440 - Add clarification for authors of JS where the gotchas are [on Doug Schepers - due 2009-11-10].

<shepazu> these are unicode scalar values

<chaals> RATIONALE: WebIDL makes sure that this comes back in the relevant form for whatever language you are using

<Hixie> to aid developers we probably need to make the non-character values (like "F1") be not length-2

<Hixie> e.g. "[F1]" or "*F1" or "F-1" or "Function1" or something

<chaals> NL: when I do 秀, how many events are there?

<chaals> [it took me about a dozen key presses to make that character]

DS: when you have IME, you have there's a bunch of composition events'n'stuff
... the whole things is very complicated. Might be best for people to review the spec

AP: when should we review

CM: over lunch

DS: the sooner the better
... spec should be pretty stable now. Especially with this latest resolution

<Zakim> annevk, you wanted to suggest we declare conversion methods out of scope

AvK: I propose we drop the conversion methods

DS: i would like to keep them
... we want people to deal with characters, so I think it's in scope

AvK: ES needs to solve it in a larger scope

SW: I think the right place to put it is on the ES String constructor, other languages have it there
... there are docs on the web that shows how to take a multibyte character and turn it into a numerical codepoint

DS: the code is HUGE

SW: no it's not

DS: yes it is

SW: no it's not

<chaals> [it is 15 lines]

<shepazu> http://rishida.net/tools/conversion/

DS: lets continue discussion later

CM: as a browser implementor, i don't see why i should look at a key events spec to see that i should build conversion functions for strings, or how to do it
... who would rather move it to ecmascript
... straw poll is taken...

<chaals> [Shepazu objects, no resolution]

DS: Hixie had requested that some events be defined in much greater detail, or be removed from the DOM L3 Events spec

AvK: I can represent hixie
... Problem is that it's very fuzzily defined when certain events are dispatched

TL: it's not expected that DOM Events define exactly when the events are fired
... and that the hosting language should define that
... this was also raised with progress events yesterday
... resolution was to define what the event looks like, but let hosting specs define when they are fired

AvK: mouse events for example can be just generic events. Don't need to be in DOM Events spec

DS: if there's a risk that hixie will raise objections, then i'd rather adress the issue sooner than later

<chaals> JS: Think what we did with Progress events makes sense - this spec defines what these things look like more or less, and the individual specs define how they fit in various specs in detail.

JS: can we leave it explicitly undefined when certain events are fired, and just define what the event looks like when fired. And then leave that to hosting specs to define when to fire events

oh, thanks chaals

JS: though i don't know who would define mouse events since they seem cross language

AvK: possibly CSSOM could define mouse events

<annevk> CSSOM View

CM: sounds like a meta-discussion. Would like to see specific proposals

SW: DOM Events seem like the wrong place to define when mouse events are fired since it involves hit testing
... some other spec or specs could define hit testing

CM: still sounds very meta to me

RESOLUTION: convertKeyValue will be removed from DOM L3 Events

<chaals> closing ISSUE-110

if you can't follow that part of this transcript, I don't blame you

<chaals> in recess

<annevk> (after further consideration DS withdraw his objection)

<annevk> close ISSUE-110

<trackbot> ISSUE-110 Should we remove the code-point conversion from the D3E spec? closed

<Hixie> i'm in i18n but i'd like to attend the database stuff

<Hixie> so i'll be down when i can

<chaals> ok. we start at 13.30

<Hixie> just call me Hixie :-)

<Hixie> or you can call him the Other Ian

<Hixie> either works :-P

<Dashiva> IIan

<chaals> ageenda+ different storage systems

<Hixie> i can answer questions, not sure i have much to say though

<Hixie> i'm happy to have a quick q&a

<chaals> ok, we'll see if people have questions and schedule some time if so.

<timeless> ScribeNick: timeless

<chaals> pablo, did you get the code?

<scribe> Scribe: timeless

<pcastro> yes, thanks, will call in in a minute

different storage systems

<arun> pcastro, are you on the phone as well?

Web DB (sqlite)

Multiple storage systems

chaals: We have a lot of these. how many are in conflict. how many are competing

<Hixie> IH: none and all respectively

sicking: Web DB and Web SimpleDB are competing
... whatever we come up with for Web DB / Web Simple DB will replace a lot of localStorage

IanF: Are people trying to throw localStorage out the window or discourage it?

sicking: the way things are going, localStorage is going to be racy
... even storing the numbers between 1 and 2, you should probably not use it

chaals: at opera, we implemented web db
... we looked at web simple db. we found the nikunj one and simple

<arun> Web DB = The SQLite One

<arun> WebSimpleDB = The Nikunj One

chaals: we found Nikunj to be more to our liking

<pcastro> arun: yes i'm on the phone as well, trying to follow

chaals: we have implemented WebDB internally

sicking: we don't have a data point
... we've had a lot of discussions, primarily with MS and Oracle
... Oracle stands behind Nikunj
... we've talked to a lot of developers
... the feedback we got is that we really don't want SQL

IanF: We've implemented WebDB
... we're about to ship it

MJS: We've implemented WebDB and have been shipping it for some time
... it's shipping in Safari

<annevk> IanF: we're also interested in the Nikunj One

MJS: the Chrome implementation shares some but not quite all of the code
... beside shipping it, web sites have versions that target the iPhone and use it
... we can't easily drop it in the near future for that reason
... In principal, having a storage mechanism that is more sound than localStorage
... but more simple than WebDB would be good
... wrt localStorage, the current bits indeed have race conditions
... but adding APIs could possibly fix it
... SimpleDB / WebDB is probably impossible because of <too much something>

jorlow: a large percentage of a lot of the web apps that google is looking at
... would need a large percentage of what is in SimpleDB
... in order to make an extended localStorage usable
... it would be fine to make localStorage do it, but it would require a lot of SimpleDB

MJS: [lost]

We can make simpleDB do everything localstorage does

Nikunj: (to MJS) do you want to keep the API as is or the functionality as is
... the localStorage API is synchronous only

MJS: you would need to do a superset in order to handle locking

jorlow: Google is not happy with the various proposals

AB: Microsoft's position is that WebSimpleDB is what we'd like to see
... we don't think we'll reasonably be able to ship an interoperable version of WebDB
... trying to arrive at an interoperable version of SQL will be too hard
... what people want is a ...
... we think that WebDB (?) features is a starting point
... we don't plan to add to localStorage

jorlow: so you don't enhance localStorage...for example, implement the storage mutex

AB: localStorage won't go away
... but we don't intend to extend it
... we don't think that people will be able to benefit from making it more complicated (?)

sicking: I haven't thought about the idea of extending localStorage
... before i form a strong opinion, i'd like to see a proposal, but it seems hard

PC: [?]

michaeln: SimpleDB doesn't overlap with localStorage
... there are no events in SimpleDB

MJS: so it isn't a superset of (localStorage) functionality

<chaals> PC: Don't see that it is interesting to try and extend localstorage

sicking: there's always value in having less features

MJS: localStorage is rather nascent, but it seems rather unfortunate that we're discussing orphaning it

<pcastro> yes, i agree, extending localStorage to cover the functionality of SimpleDB is the same as introducing a new simpledb API, given the delta...

sicking: I agree, but i haven't seen any workable proposals

PC: localStorage is useful for simple tasks
... for registry keys (preferences) in windows apis

sicking: the problem with it is the raciness
... no one working on a multi process browser has safely handled this

chaals: we're out of time.
... there's a lot of push for Nikunj
... where does that leave WebDB?
... Apple can't stop shipping it
... Google will be shipping it
... Opera has not yet shipped it
... but it's likely we will as people have built on it

sicking: I don't think mozilla plans to ship it

DS: you could do the same things with Nikunj as with localStorage
... except storage events

PC: the difference is...
... you get the ability to have a lot more data in it
... in a much more organized way

<annevk> (there's also sessionStorage, fwiw)

PC: you don't need to learn another language to get data in/out

chaals: i don't see a conclusion

sicking: I don't have any plans to review WebDB

IH: I'd rather not spec WebDB if people don't want to ship it

DS: I was talking with w3c people about the confusion
... there are several web storage proposals, and we think that it clutters developer mind space

IanF: I don't think people are in disagreement that it's sad
... it's a bit too late

WebDB - sql lite

IanF: let's look at something else, but let's move on

cwilson: I don't know if anyone has suggested on the group of killing off WebDB on the list

DS: except the editor

[ laughs of agreement ]

MJS: it sounds like there will be multiple shipping implementations

cwilson: it seems with multiple interoperable implementations
... that you can't really call it stillborn

<ifette> s/q+

cwilson: when we started looking at WebDB
... the reason we liked Nikunj was that it doesn't impose
... but it has the power
... the part that concerned us with WebDB is that it presupposes SQLite
... we're not really sure

IanF: i don't think anyone disagrees
... I haven't heard anyone say they don't like Nikunj , i've heard a lot of interest in it

IH: Proposal
... all the browsers shipping WebDB are WebKit based
... proposal: we move WebDB to WebKit.org, and we kill it as a deliverable from this group

chaals: I think we're likely to ship it

IH: I don't want to work on a spec without 5/5 impls

DS: Is it possible to take what is speced in WebDB, freeze it,
... take the interface layer, and stick it onto Nikunj ?

[all] : No.

arun: suppose the freezing part was taken seriously
... is that sufficient, or is there more spec needed to be written?

IH: well, there's the SQL part
... we could say that the SQL part is SQLite 3's dialect

<ifette> sam: spoke

Sam: Apple and Google have expressed an interest in added full text search to the api we've used

jorlow: that's extremely important to Google too

[ audience squirmed relating to some Xsomething api]

IH: most of the people are asking me to spec Nikunj (?)

chaals: moving along
... proposal: WebDB remains as a deliverable
... we ask IH to do the minimal level to satisfy the implementors


<ifette> RESOLUTION: hixie does minimal work to get this to a point the shipping browsers are happy with, if he goes nuts we will put up resources to finish it


chaals: do we really want to talk about filesystem?

arun: no

ifette: no, except to remember it exists

<chaals> zakim drop agendum 5

Web Simple (Nikunj) DB (nikunj)

chaals: ack Nikunj

[ Nikunj asks for projection ]

[ chaals asks for intros from lurkers ]

Donald from ETH Zurich

Donald: We've implemented XQuery that runs in IE and FF, and hopefully soon in Chrome/Opera/Safari

Ghislain a student of Donald

Dana from Oracle

HTML working group chair


Gondo from Toshiba

Nikunj: there's a new draft, taking input from others and feedback from the mailing list

<chaals> Magnus, Ericsson

Nikunj: there are some use cases we don't cover
... JS might want to do boolean expression evaluation
... the language for the expression isn't important
... but the necessary bits to efficiently implement this
... being able to store keys, iterate over keys in the index, operate over multiple keys at the same time
... I plan to add appendices to help with this (?)
... before the next working draft
... there are some open questions that i haven't addressed in this spec
... i'd like to lay out things to get feedback for alternate suggestions
... first, key types
... string/number
... the are fancier things that could be done, supporting structured clone as a key value

<chaals> [functions that evaluate to a value can be a key, too]

Nikunj: there are various ways to make it fancier
... there are multiple ways to address this
... there are three ways to do indexing
... 1. no indexing, the application manages the index manually
... 2. the index only knows about the store, but the useragent doesn't maintain that index
... it is only used by the application to look up things through the index
... 3. in addition to 2, the useragent actually maintains the index
... option 1 is supported
... option 3 is supported with constraints on the key path
... option 2 is not supported
... option 3 is a simpler api but more complex implementation
... there's a contention between reducing the footprint of the api v. the footprint of the implementation
... there are tradeoffs across different engines
... i've tried to capture an implementation neutral api
... i'm requesting feedback to be categorized, api v. footprint
... i've received feedback on concurrency
... there are two models for concurrency
... optimistic and pessimistic
... i've tried to avoid mandating an implementation
... implementations will choose based on their needs
... optimistic is better for high performance
... pessimistic is simpler
... in the spec, i've tried to identify conditions that can offer deadlock free behavior
... i believe the main concern, is that the average user will not be very good at recovering from
... deadlocks or optimistic concurrency failure
... the approach i've taken is to specify a behavior that is deadlock free
... and specify two levels of granularity that
... at the database, or an object store

ArtB: could you document this in a blog?

Nikunj: Object Store = Table

DS: better in a requirements document than a blog

<chaals> --> http://dev.w3.org/2006/webapi/WebSimpleDB/ editor's draft

Nikunj: let me start writing it in an appendix, and then we can move it to another document later

<Zakim> ifette, you wanted to ask question aboujt indicies

<ifette> \

Nikunj: two levels of deadlock free concurrency
... comparing with WebDB
... where we only do database level concurrency

<chaals> scribe: Chaals

Nikunj: and object store level
... main point is that people have asked for even more concurrency where possible.
... optimistic concurrency control and management, but there is a risk of failiures in concurrency management that exposes programmer to requiring recovery
... proposal is to allow that to programmers through existing API knowing that can lead to exceptions that need recover
... could be left out, would be easy to implement in any DB that allows that leel of concurrency. Question for the working group (and whether people like it)
... Propose to leave it in, as an appendix outside the basic part so people don't stumble.

IF: Wanted to jump back to indices. What do the 3 options mean for an app developer with a lot of data
... assume 20GB database of integers. Which option gives me a Btree in the user agent, instead of in JS

NM: The btree is in the user agent. you only pull out the data you are looking to consume.
... to find out which pieces of data match the two conditions, you have to do the join yourself.
... People feel that a user agent implementation of that might be too rigid, and doing it in the app will be almost as performant.
... Limiting the amount of data you pull out will be easier for the app than the UA to get right - but this is open to feedback

IF: Scares me but I need to go back and get more detail.
... What base index types do you expect all UAs to support?

NM: Use case for me is a boolean index exression evaluation. Another use case is keyword and context - fulltext.
... you could create keword/context index, but will not perform as well as done natively.
... We can include that but it isn't included in the current draft - or we could put it in a v2. There is also hashindex which is not specced - we just have btree.

IF: To use this for gmail we have to be able to do fulltext and we don't think we can do that performant in JS so we would like native code to do that.
... For v1

NM: In some discussions we can provide keyword/context, but fulltext incoroprates some more concepts that can get hairy in different languages. It should perform aequately with a qiuck index.
... fulltext is probably a bigger spec than websimpleDB.

[clarification of fulltext vs keyword/context]

IF: If we had a quick index that might suffice... let's come back

JS: The issue I found most controversial internally has been the concurrency issue

[ed. Jonas said the unfancy word :P]

JS: In general we aim to avoid race conditions and deadlocks. sql api uses a simple lock - touch it once and everything locks until you leave it - no risk but performance issues.
... I have argued that there are a range of solutions between the extremes, where we can lock fine-grained without having the risks. Should we try to find such a solution or say people who use this need to be smart enough to deal with such lock/race conditions.

NM: Share your concerns in dumping deadlock recovery on programmer. THink spec as written now has more concurrency than usual - offers a model where readers don't block writers so long as they are not on the same bit.
... If application doesn't want to choose, we do the safe thing. If they want to choose they can have deadlock-free concurrency. Open to hearing of such mechanisms we can offer, and found 3

IF: 3 options are all guaranteed to be dealock-free. Is that a hard requirement or could we offer low-level locking ???

NM: That is possible and is supported in the spec but doesn't mean that we have to have it. Have been warned that optional behaviours don't get implemented or cause introperability problems.

JS: There had been an idea of allowing a fallback to a locking model, but optional features generally lead to a race to the bottom. Think we should mandate that all locking mechanisms are required.

NM: Yes you can add levels of granularity as well as deadlock free mechanisms

<Zakim> jorlow, you wanted to full text indexes

JO: Question about joins - sounds like you took them out to keep the implementation simpler

NM: And keep the API smaller

JO: Main concern was implementing joins in Javascript.

NM: Spec was originally written on berkeleyDB which had no way to retrieve object based on key index. had a way to join dbs but we added a way to lookup an object from the index and treating the indices, and use of joins dropped.

JO: So if you have two large parts of the DB with small verlap, doing that in JS is going to be inefficient.

IF: Fulltext is an example - like that.

JO: In Gmail example, if you are searching for a to and from address you might have zillions of addresses so it might be a big burden on the system

NM: there is no expectation in the set that an entire dataset has to go into memory. because itis btree the two indices are sortedin the same order so it reduces the amount you need to work over.

JO: If you have 10k items, that's heavy

NM: Marshalling cost is high

IF: When using the same index repeatedly, how complex?

NM: if needed it would be an extrsa feature in the spec

SW: concrete question - a person coming from SQL API - how different is the code they have to write, what is the conversion

NM: A user programming against the API?

SW: Sure

NM: In use cases, we don't expect people to program against the spec, but use JS libraries. But we want to make it possible to program against directly.
... if you are using a mapping laer here there will be no real difference

SW: Is there precedence for adding a new API mostly for middleware?

Timeless: We added a lot of stuff to libraries against APIs

AR: It is wise to look at this API to make simple things simple, but look at allowing libraries to straddle it.

SW: Not sure that this is simpler for a simple query, which is the basic use case for a DB

AR: Not sure how much more simpler it will be to use SQL

<ifette> jonas: most people use XHR via libraries

JS: XHR is generally used through libraires - there are direct usage but a lot of Dojo. The other one is the WebGL, that is meant to be used like that

SW: remains to be seen for WebGL

AR: Think XHR is a good answer for Sam's question.

SW: Would like to see simple examples converted and how easy they are

NM: Those are already in the front of the spec.

JS: Depends heavily on the SQL string that you are passing in. Lots of X-table joins will be harder, looking up simple table stuff is just as simple.

IF: In terms of the world, Mozilla won't implement WebDB, and we want to get Gmail working with a DB and there are others who want to get apps working. Plus or minus some detail, it seems Web Simple Database can do taht
... I can make my app work with this probably.

AR: Would like to see libraries that straddle this


SW: It would be nice to see a performance analysis

NM: Yes, we need implementation experience to do that.
... Bulk of feedback on data caching / http interception seems like appcache but it uses different terminology.
... people didn't know what they would need to make it happen.
... Working draft published last week uses same mechanisms as appcache to describe it. Not identical. The model by which application ahs access to the cache is similar. There are a few differences
... appcache doesn't take full headers into account, data cache does
... When first adding something to the datacache the value was in a cookie and the ambient auth is matched against the cookie value without the app specifying stuff for offline auth.
... works as expected for online auth. Means there is ont just one datacache - ther are different cookies that authorise different things in the same origin, so different caches.

MM: Browser has several forms of auth. reason to check cookies seem to apply to http auth as well.

NM: Yes, that is very valid. In this ersion we are only dfoing cookie, but no reason why it has to be that way.
... Since synch is app-controlled there are difference to appcache. timing is different - has to happen when the app kicks in. 2nd, data items to be fetched have to be identified.

see example 4.1.1 in datacache draft

<jorlow> chaals: I can do it on list

scribe: roughly equivalent to what you do in app cache. app cache doesn't provide direct access, but data cache needs that to decide what further stuff gets synched. Ususally happens in a long-running single transaction. API provides a way to control synch, or do offline transactions - instead of doing capture by a URI alone you can do offline transaction specifying URI and the bits representing the URI that could be used later in a request made by

the app.

scribe: Understand this raises concerns and we should discuss. As well as GET and HEAD you can use PUT POST or DELETE where there is an interceptor registered on the navigator object similar to protocol handlers.

MJS: You mentioned feedback was about relation of this to appcache. (I gave some) looking at the draft it looks like at least two of my most important points are not addressed. If I ahve both appcache and datacache, how do they intersect. Your spec doesn't decsribe taht. Would prefer a single API with union of capabilities.

second CORS

<arun> scribenick: arun

mjs: [May present a short slide show]

<annevk> hmm, no adam :/


<chaals> Jeff Hodges, Paypal

mjs: Gives a presentation on CORS that he commits to putting online soon.

MM: [Points out that "secret token" addresses issues in Origin]

<chaals> MJS: In access grant (CORS case) you need to add origin check or token (as normal) to protect against CSRF.

mjs: [In the common case, where you're logged in, and permission is granted, diagram illustrates CORS]

TC: There's an implicit trust relationship between the Events site and the Calendar site.
... The party that could be attacked here -- the Calendar (via confused deputy) -- could be attacked by Event page. Event page (Server B) can trigger an inadvertent action on Server A (the Calendar site)

TLR: Turn Server A into an AtomPub server. You want to create a resource, you get the identifier for the resource returned. resource on Site B uses AtomPub to do something on Server A
... B, the event Page, creates a resource on A. B does not know in advance what the URI of the event would be. A returns a URI. B could inadvertently phone home to A and create [error condition]

MJS: If Server A only responded with the path part of the URI, there would be no such vulnerability.

TC: But this may also eliminate valid use cases!

MM: Let's contrast this with the same scenario, where you're using a per-resource secret token, along with the designator. In that case, access is allowed based on presented authorizing info. When you go to AtomPub service....

TC: when this slide was presented, he asserted there was no confused deputy possible in this scenario. But with little effort, I created a confused deputy here.

<Hixie> ...by introducing a new protocol that has a vulnerability

MJS: [slide show continues]
... Server M can't forge Origin in browser, combination of cookie + Origin identifies request as valid
... Fancier scenarios can have confused deputy. Site A asking Site B to do something on Site C
... Can also have confused deputy problems without CORS. For example poorly implemented secret tokens.
... [Diagrams this on paper]
... [ Draws sites A, B, C]
... illustrates a scenario where B,and C have an understanding with shared tokens.
... It's an isomorphic problem. A only tells B a resource to act on. B then talks to C. This creates a vulnerability since what A asks B might not be what B is expecting to do.

TC: THe thing that makes CSRF prevalent is that the two initial messages between B and C happen implicitly and automatically.

MJS: CSRF is different. I am simplifying here by considering only servers.
... With CORS, in my simple scenario, doing the dumbest possible thing will be safe.

JS: The simplest way to do authorization on the web today is to use cookies; ergo CSRF problems common

MJS: Here is my claim on how to avoid confused deputy problems: don't be a deputy! If you follow this discipline, purely local to your server, you will not have a confused deputy problem.

MM: But you will also have a lack of composability amongst servers!
... I think there might be the issue of "on behalf of." In Tyler's scenario, the "on behalf of " is not that Tyler made a request on behalf of the deputy.

MJS: That has to count as on behalf of.

TC: This means that whenever you send in a request, you have to make sure it doesn't include data you got from anyone else.

MJS: It means that if it does, it is distinguishable from any data from that particular server.

IH: Or you make sure sanitization takes place (a la SQL injection)

TLR: If you want to sanitize, then you must know what the consumer might possibly trigger

MJS: [slideshow continues]
... [gives the example of GMail / Linked In where LinkedIn asks for GMail passwords]

MM: They would prefer to do something else.

MJS: What are non - CORS solutions that could work?
... OAuth could work, generally requires server to server communication. Bilateral agreement (shared secret)
... [Diagrams an OAuth scenario]
... [It is a complex diagram]

JH: [Has a better diagram]

MJS: This is not only in your user agent; it must be programmed in server software.
... You cannot send your shared secret to the client.

MM: This is per request?

MJS: It doesn't have to be per request. The protocol allows token to be valid for e.g. 1 hour.
... [discusses OAuth; ] Request token is combined with a particular user; get an authorization token from Site B (combination of particular user, etc.). Event page has to redirect, etc.
... [Continues discussion of OAuth] Redirects are part of the model.

<JeffH> http://identitymeme.org/archives/2008/10/22/oauth-protocol-flow-diagrams/

MJS: [ Discussion of OAuth model] Flaws: server to server communication is mandatory. And it's hard to implement correctly.
... Discusses why CORS is an improvement of what is done today.

RE: Also worth discussing is JSONP, which is horrendously evil.

JS: Asks Microsoft -- have you disabled Cookies for cross-site script requests?

AB: [Responds yes]

MJS: That fixes vulnerability on the site serving the script....
... I hope to have brought folks up to speed [slide show].

<MikeSmith> some other OAuth diagrams: http://old.sitepen.com/labs/code/ttrenka/oauth/oauth-sequence.png http://oauth.googlecode.com/svn/spec/branches/1.0/drafts/6/diagram.png

CMN: This is the model used by "Verfied by Visa" right?
... If this is the same basic schema used by Visa and MasterCard, then that gives you proof that the (OAuth) model is used and in circulation.

MJS: I would not claim it is impossible to implement.
... But it might be hard for the casual site developer.

AR: [Points out that we did this to improve the world]

TLR: Two frames, + postMessage. Wouldn't that address this problem?

MJS: So a frame (content that's meant to be loaded in an iFrame) is a cross-site data API. If you use it in the kind of way that Tyler Close identified, it would also have the same Confused Deputy Vulnerability..
... Additionally, it needs client side scripts making requests to the API.

TLR: The distinction is that client side code checking origin occurs on the client, as opposed to the server.

MJS: Our worry is not about people making the origin check, but in drawing the wrong conclusion about the implications of the Origin check.

<Hixie> IH: You can have a dedicated API with a server-provided API or a JS API

<chaals> ACTION: Nikunj to respond to Maciej about how to use appcache and data cache together on a client, and whether there can be an API which is the union of appcache and datacache [recorded in http://www.w3.org/2009/11/02-webapps-minutes.html#action09]

<trackbot> Created ACTION-441 - Respond to Maciej about how to use appcache and data cache together on a client, and whether there can be an API which is the union of appcache and datacache [on Nikunj Mehta - due 2009-11-11].

MM: I want to make the proposal that the GuestXHR proposal can meet all requirements. Requirements: grant permission once, no manual steps to copy data between sites, AJAX UI, no server to server, no need for prior bilateral agreement between servers.

MJS: I'd like to analyze this like we've analyzed CORS

TC: I'd like to show you a solution that is more secure, and doesn't use an Origin header, would that satisfy your concerns?

MJS: I'm interested in seeing solutions that satisfy the requirement that doesn't introduce protocol complexities, etc., and I'm interested in understanding that given that some browsers ship CORS, I'd like to understand whether the compatibility issues are worth it.

CMN: I am concerned that we don't work in vacuums, we work in places where people have products. I am generally concerned in standards work about shifting goal posts. One more example, one more thing... I understand that you might feel that way. Such is the lay of the standards land. I would like to see
... .... a worked example.

MJS: I shall send it to the list.

<chaals> ACTION: Mark to make a worked example of how e.g. GuestXHR would meet the requirements with improved security [recorded in http://www.w3.org/2009/11/02-webapps-minutes.html#action10]

<trackbot> Created ACTION-442 - Make a worked example of how e.g. GuestXHR would meet the requirements with improved security [on Mark Miller - due 2009-11-11].

MJS: In a standards compliant format, so that nobody has to live with my company's proprietary format (Keynote)

CMN: ONe of the things that make high bars is that we're going to open up our users to abuse. There comes a time when you turn off services.

MJS: There's a balance between security and compatibility. If there's a vulnerability where you break compat by fixing it, I'm sure all browser vendors would be eager to do it. If there's a vulnerability that's [mild] e.g. visited links, we may not break compatibility.

TC: A lot has been made of the existing deployment of CORS. From my study of the specs, there are significant differences between implementations...

CMN: These are [decisions made] by implementors based on the perceived cost to them.
... I don't think security is an on and off thing.

<chaals> TC: And therefore I am wondering if there is significant content in reality.

<chaals> AR: There is shipping and compatibility, in apps there is really only geonames, not a great deal of other adoption




The URL above shows content working in safari and firefox

[General discussion on TC39/WebIDL]

Multi-touch events

<annevk> scribe: annevk

AR: Safari is shipping multi-touch (mt), Firefox will be soon
... there are patent risks, but I think we should wait for the exclusion period and see what happens
... I think the charter allows for mt

<chaals> http://www.w3.org/2005/06/tracker/webapi/issues/33

DS: people disagree on whether it is in the charter
... it is not listed as deliverable, but is in scope
... if someone in the WebApps WG disagrees it is in the charter we have to re-charter in order to do it

RE: we might want to talk to the Device APIs WG

AR: also include orientation event in mt

DS: I believe they are orthogonal so they can be separate

AR: I believe the same group can do it

CMN: we had an issue in the last WG that we inherited about multiple devices interacting with a single device
... sort of similar to mt

JS: I think it is different, not just in semantics

CMN: write a spec for mt events
... the spec says it expects to be included in DOM4 Events

AR: I favor separate specs


AR: I am willing to co-edit

DS: I like to co-edit

AR: I like to check with OP

[bikeshed on charter]

CMN: are there objections to adding new events?

RESOLUTION: specifications for new events are in our charter

CMN: we have proposals for mt, orientation, gestures, and pen-tablets

<MikeSmith> I believe the Geolocation WG is also looking at spec related to Orientation

CMN: we have volunteers; DS and AR

[group overlap bikeshed]

RESOLUTION: DS and AR edit multi-touch, orientation, gestures, and pen-tablets events specification

[pen-tablet bikeshed]

SO: joystick etc. events?

CMN: if you have proposals

joint meeting with widget fanboys

<ArtB> http://www.w3.org/2008/webapps/wiki/PubStatus#Widgets_Specifications

<ArtB> http://www.w3.org/2008/webapps/wiki/PubStatus#API_Specifications

AB: editors please fix if there are mistakes

MC: I wonder how XMLHttpRequest and CORS are going to be tested

SW: You can use one domain with two different ports

DS: we can ask the systems team

<chaals> send mail to team-webapps@w3.org

DS: can we start a wiki page with a list of required features for tests?

AB: we have two dependencies; Web IDL and Web Storage

SW: Web IDL will use ECMAScript 5 concepts which is an invasive change
... we want to add tests based on DOM2 IDL converted to Web IDL so we can test the various concepts in Web IDL
... we can use that to allow specification editors to move forward with more certainty

JS: I volunteered for some amount of that testing

CMN: you can move ahead in the Rec-track process with a dependency on Web IDL but you have to argue your case

AB: when is there a new draft?

SW: I'm new to editing so I don't really know at this point

MJS: the question is how much editing needs to be done before we want to publish again
... maybe the goal should be to do the ECMAScript 5 conversion and publish after that

IH: Web Storage will go to Last Call this month

CMN: we want to move to a model where Last Call means the Working Group considers the work to be good

IH: I believe there are no outstanding issues
... The W3C side will not be blocked by the WHATWG
... I don't perceive major changes to Web Storage ever

<ArtB> ACTION: barstow send out a pre-LC request for comments for Hixie's specs [recorded in http://www.w3.org/2009/11/02-webapps-minutes.html#action11]

<trackbot> Created ACTION-449 - Send out a pre-LC request for comments for Hixie's specs [on Arthur Barstow - due 2009-11-11].

CMN: we found someone to edit ??? and agreed to move XMLHttpRequest to Last Call
... Web Database was only going to be done by 3 out of 5
... more interest in WebSimpleDB
... alternate proposal for CORS which needs further discussion; DOM Events ready
... we did not get into Selectors API 2

AB: news on XBL2?

JS: I'm on temporary project for a while, but I worked on a quarter for it and will get back to it

<ArtB> ACTION: barstow start a CfC to publish FPWD of File API [recorded in http://www.w3.org/2009/11/02-webapps-minutes.html#action12]

<trackbot> Created ACTION-450 - Start a CfC to publish FPWD of File API [on Arthur Barstow - due 2009-11-11].

[thanks bikeshed]


Summary of Action Items

[NEW] ACTION: ArtB to notify Widgets WG that they have 2 weeks to review WARP [recorded in http://www.w3.org/2009/11/02-webapps-minutes.html#action05]
[NEW] ACTION: barstow send out a pre-LC request for comments for Hixie's specs [recorded in http://www.w3.org/2009/11/02-webapps-minutes.html#action11]
[NEW] ACTION: barstow start a CfC to publish FPWD of File API [recorded in http://www.w3.org/2009/11/02-webapps-minutes.html#action12]
[NEW] ACTION: chaals to raise an issue for this question [recorded in http://www.w3.org/2009/11/02-webapps-minutes.html#action02]
[NEW] ACTION: jonas write a very concrete example of a problem [recorded in http://www.w3.org/2009/11/02-webapps-minutes.html#action03]
[NEW] ACTION: Mark to make a worked example of how e.g. GuestXHR would meet the requirements with improved security [recorded in http://www.w3.org/2009/11/02-webapps-minutes.html#action10]
[NEW] ACTION: Nikunj to respond to Maciej about how to use appcache and data cache together on a client, and whether there can be an API which is the union of appcache and datacache [recorded in http://www.w3.org/2009/11/02-webapps-minutes.html#action09]
[NEW] ACTION: shepazu to add clarification for authors of JS where the gotchas are [recorded in http://www.w3.org/2009/11/02-webapps-minutes.html#action08]
[NEW] ACTION: travis To research what IE does for readystate re-entry (for ISSUE-33) [recorded in http://www.w3.org/2009/11/02-webapps-minutes.html#action06]
[NEW] ACTION: Tyler to explain how to do it with guestXHR in a nice UI [recorded in http://www.w3.org/2009/11/02-webapps-minutes.html#action04]
[NEW] ACTION: weinig to clarify method overloading section and make it readable [recorded in http://www.w3.org/2009/11/02-webapps-minutes.html#action07]
[NEW] ACTION: weinig to write up sample on what the multi-file progress informative text might look like. [recorded in http://www.w3.org/2009/11/02-webapps-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009/11/04 02:05:34 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/Shigeo/Shiki/
Succeeded: s/Erik/Per-Erik/
Succeeded: s/progress/processes/
Succeeded: s/has not/has not/
Succeeded: s/has not/has no/
Succeeded: s/ways/way/
Succeeded: s/hesitat/hesita/
FAILED: s/vous/vour/
Succeeded: s/For/fROM/
Succeeded: s/chaals/maciej/
Succeeded: s/jonas/anne/
Succeeded: s/adjourned/in recess/
Succeeded: s/adjourned/in recess/
Succeeded: s/ack:/avk/
Succeeded: s/coordination/coordination... I would be happy to have it worked on jointly, if we can do that, and public-script-coord should help/
Succeeded: s/VD/VK/
Succeeded: s/editing/scribing/
Succeeded: s/who volunteers to provide tests/who volunteers to provide DOM L2 based tests/
Succeeded: s/provide/fish out and expand on heycam's/
FAILED: s/じき/史紀/
Succeeded: s/SO: i do!//
Succeeded: s/しき/史紀/
Succeeded: s/"\\u1234"/"U+1234"/
Succeeded: s/surrugate/surrogate/
Succeeded: s/DS: i would like to express a resolution//
Succeeded: s/RESOLUTION: the value will be a character. WebIDL will clarify how this is mapped to ES/RESOLUTION: The return value will be a DOMstring which is the character produced. We add a note explaining to authors what happens/
Succeeded: s/web db nice/the nikunj one/
Succeeded: s/Nikunj/WebDB/
Succeeded: s/Nikunj: [lost]/We can make simpleDB do everything localstorage does/
Succeeded: s/plan to change localStorage/enhance localStorage...for example, implement the storage mutex/
Succeeded: s/cwilson/PC/
WARNING: Bad s/// command: s/q+
Succeeded: s/ianf/ifette/
Succeeded: s/DB/DB (nikunj)/
Succeeded: s/DB/(Nikunj) DB/
Succeeded: s/[?]/Gondo/
Succeeded: s/storage/store/
Succeeded: s/pont/point/
Succeeded: s/exiting/existing/
Succeeded: i/JS: my concern is that/scribenick: sicking
Succeeded: s/this/this probably/
Succeeded: s/[bike shedding]//
Succeeded: s/ffedback/feedback/
Succeeded: s/A page on B/resource on Site B/
Succeeded: s/same mechanism/ same Confused Deputy Vulnerability./
Succeeded: s/about the origin check/about the implications of the Origin check/
Succeeded: s/we may not break it/we may not break compatibility/
Succeeded: s/tehre/there/
Succeeded: s/erally/really/
Succeeded: s/nota/not a/
Succeeded: s/RI:/RE:/
Succeeded: s/event specifications/events specification/
Succeeded: s/dependency/dependency on Web IDL/
Found Scribe: Travis
Inferring ScribeNick: Travis
Found ScribeNick: Travis
Found Scribe: Chaals
Inferring ScribeNick: chaals
Found ScribeNick: chaals
Found Scribe: Sam
Found ScribeNick: weinig
Found Scribe: Maciej
Found ScribeNick: mjs
Found Scribe: Nikunj
Inferring ScribeNick: Nikunj
Found Scribe: sicking
Inferring ScribeNick: sicking
Found Scribe: s icking

WARNING: "Scribe: s icking" command found, 
but no lines found matching "<s icking> . . . "
Continuing with ScribeNick: <sicking>
Use "ScribeNick: dbooth" (for example) to specify the scribe's IRC nickname.

Found Scribe: sicking
Inferring ScribeNick: sicking
Found Scribe: Sicking
Inferring ScribeNick: sicking
Found Scribe: chaals
Inferring ScribeNick: chaals
Found ScribeNick: sicking
Found ScribeNick: timeless
Found Scribe: timeless
Inferring ScribeNick: timeless
Found Scribe: Chaals
Inferring ScribeNick: chaals
Found ScribeNick: arun
Found Scribe: annevk
Inferring ScribeNick: annevk
Scribes: Travis, Chaals, Sam, Maciej, Nikunj, sicking, s icking, timeless, annevk
ScribeNicks: Travis, chaals, weinig, mjs, Nikunj, sicking, timeless, arun, annevk
Default Present: apis-db-stuff, +1.206.369.aaaa, Chris, [Microsoft]

WARNING: Replacing previous Present list. (Old list: Chaals, Anne_van_Kesteren, SamW, Travis, Adrian, Satoshi, Frank, Maciej, Mike™, Rob, Marcus, Gondo, Vagner, Per-Erik, Vladimir, Shiki, Mark, Doug, Kai, PaulC, Sam, JohnG, Jeremy, Nikunj, ArtB, TAG, timeless)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ Chaals, Sam, Per_Erik, Vladimir, Satoshi, Shiki, Arun, Nikunj, Anne, Rob, Lachlan, Jonas, Travis, Adrian

Present: Chaals Sam Per_Erik Vladimir Satoshi Shiki Arun Nikunj Anne Rob Lachlan Jonas Travis Adrian Maciej Doug Sicking MikeSmith Julian Ishida Addison NorbertL Hixie Mike™ Felix Marcos Benoit
Agenda: http://www.w3.org/2008/webapps/wiki/TPAC2009APIs
Found Date: 02 Nov 2009
Guessing minutes URL: http://www.w3.org/2009/11/02-webapps-minutes.html
People with action items: artb barstow chaals jonas mark nikunj shepazu travis tyler weinig

[End of scribe.perl diagnostic output]