17:04:06 RRSAgent has joined #webapps 17:04:06 logging to http://www.w3.org/2009/11/02-webapps-irc 17:04:12 scribe: Travis 17:04:17 scribeNick: Travis 17:04:21 Marcos has joined #webapps 17:04:35 adrianba has joined #webapps 17:04:49 Topic: Introductions for Persons present at the WebApps TPAC Meeting 17:04:53 mmielke has joined #webapps 17:05:05 myakura has joined #webapps 17:06:14 evlakat has joined #webapps 17:06:45 MikeSmith has joined #webapps 17:06:58 ArtB has joined #webapps 17:09:28 Present: Chaals, Anne van Kesteren, SamW, Travis, Adrian, Satoshi, Frank, Maciej, Mikeā„¢, Rob, Marcus, Gondo, Vagner, Erik, Vladimir, Shigeo, Mark, Doug 17:09:32 Vagner-br has joined #webapps 17:09:32 Chair: Chaals 17:09:40 fo has joined #webapps 17:09:51 s/Shigeo/Shiki/ 17:10:20 timeless has left #webapps 17:10:43 s/Erik/Per-Erik/ 17:11:13 Present+ Kai 17:11:27 http://www.w3.org/2008/webapps/wiki/TPAC2009APIs 17:11:34 RRSAgent, make minutes 17:11:34 I have made the request to generate http://www.w3.org/2009/11/02-webapps-minutes.html MikeSmith 17:11:37 Agenda: http://www.w3.org/2008/webapps/wiki/TPAC2009APIs 17:12:00 Topic: Progress Events 17:12:01 Kai has joined #webapps 17:17:01 chaals: Any additional items to add to the agenda? 17:17:42 Present+ PaulC, Sam, JohnG, Jeremy 17:18:14 chaals: Spec has been stalled for some time... 17:18:14 plh-webapps has joined #webapps 17:18:59 Present+ Nikunj 17:19:04 Topic: Progress events 17:19:14 --> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.32 Editor's draft 17:20:06 johnnyg has joined #webapps 17:20:48 chaals: Progress events are events for showing progress :-) 17:21:45 JonathanJ has joined #webapps 17:21:51 smaug has joined #webapps 17:22:20 ... Issue about what events must be defined in the spec itself. 17:23:01 ... Justification is that there is a definate pattern that must be followed when implementing these events. 17:23:39 ... Progress events have been implemented by SVG some years ago (there a bit of a legacy) 17:24:13 ... Considering making the events requirement a "SHOULD" instead of a MUST. 17:24:40 ... This text presumably makes it easier to integrate into other specs. 17:25:47 Hixie: Main concern with the requirements able to be defined in other specs and the progress events spec is how do you test this? 17:26:52 shepazu: Can progress events be implemented outside of a host language? 17:28:08 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. 17:28:39 shepazu: Concerned that an implementer wouldn't implement the non-normative parts. 17:29:11 chaals: With a spec only having SHOULDs, there's no normative requirement for implementors! 17:29:24 ... Would such an approach make sense? 17:29:38 arun has joined #webapps 17:30:02 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. 17:33:09 chaals: Without a normative requirement, there's nothing to prevent anyone from completely ignoring the spec. 17:35:08 Rob: Would it make sense to have a section for reasons why the Progress events wouldn't be used as spec'd? 17:36:23 shepazu: Question about what the different use cases are for when scenarios might employ progress events. 17:36:49 smaug has joined #webapps 17:37:32 eric_uhrhane has joined #webapps 17:37:34 for example, you could use progress events for computationally intensive progress 17:37:50 s/progress/processes 17:38:25 mjs: Should have a section for how Progress events should "typically" be used (in a basic scenario), but to not overconstrain the spec. 17:39:44 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. 17:40:22 anne: Don't think it makes sense to have user agent requirements in this spec. 17:40:51 Hixie: There are conflicting requirements must / must not depending on the spec. 17:41:30 anne: XHR, AppCache, Media Elements all specify how these events are to be dispatched. 17:41:38 ... So don't see the point of a common model. 17:43:07 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. 17:43:22 Hixie: Great--as long as it's not normative, I love it. 17:43:30 shepazu: +1 17:43:59 anne: Seems pretty complicated to a make a generic model. 17:44:03 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 17:44:13 these requirements would not be normative at the progress events spec level 17:44:41 anne: No formal objection. 17:45:34 If it is non-normative, issues behind objections can probably be mitigated (e.g. how complicated a general model might be). 17:45:50 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 17:46:23 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 17:46:58 Hixie, so HTML5 has not normative dependency on Progress events currently, right? 17:47:01 johnnyg has joined #webapps 17:47:13 s/has not/has not/ 17:47:17 s/has not/has no/ 17:47:24 anne has left #webapps 17:47:24 chaals: Issue 105 17:47:27 http://www.w3.org/2008/webapps/track/issues/105 17:47:27 it has one for appcache 17:47:58 anne has joined #webapps 17:49:20 mmielke has joined #webapps 17:49:26 ... Use cases for my "email scenario" and the Media streaming events were different. 17:51:17 ... Was my addition of the attribute for tracking different transactions useful? 17:51:41 Hixie: The model you describe (with sub-transactions showing progress) leads to horrific UI. 17:51:50 chaals: Yes, but I like that UI. 17:52:52 smaug__ has joined #webapps 17:53:01 arve has joined #webapps 17:53:20 "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 17:53:21 shepazu: In the multiple items case, could I make a progress bar that handled X different items downloading at once and consolidate them? 17:56:02 Rob: Might want to make this very simple and keep the progress as percentages only. 17:56:20 chaals: On percentages: this can get tricky when you don't know how much data you're going to get. 17:58:22 MichaelNan: In favor of simplifying the progress events. 18:01:05 johnnyg has joined #webapps 18:01:25 timeless_mbp has joined #webapps 18:01:44 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. 18:03:53 tlr has joined #webapps 18:04:12 chaals: The purpose of the two extra attributes was to allow the data for sub items to be tracked. 18:05:51 weinig: For the non-simple cases, an informative section describing how to handle these might be easier. 18:06:26 Hixie: Could look to XHR's upload concept. 18:07:34 http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-upload-attribute 18:07:47 Action: weinig to write up sample on what the multi-file progress informative text might look like. 18:07:47 Created ACTION-431 - Write up sample on what the multi-file progress informative text might look like. [on Samuel Weinig - due 2009-11-09]. 18:09:13 chaals: Issue 107 is largely redundant if we simplify. 18:10:11 chaals: There is another question: what does the total and loaded count mean? 18:10:19 ... Now is specifies the number of bytes. 18:10:56 ... In removing the normative requirement, the "bytes" requirement could totally go away. 18:11:13 ... Makes sense for me to recommend bytes as the default simple case. 18:11:45 Hixie: So far, the various specs interpret the values different already {files, bytes, objects} 18:15:33 chaals: Propose we drop the total bytes in favor of showing progress of "something". 18:15:51 chaals, Ian Fette and Lachy came in, need to intro himself 18:16:27 Lachy has joined #webapps 18:16:43 Lachy has joined #webapps 18:17:40 mmani has joined #webapps 18:18:12 shepazu: Please keep existing text in place for a compare/contrast draft. 18:19:32 chaals: I think this wraps up what I had to discuss on Progress Events. 18:23:38 Lachy has joined #webapps 18:23:41 chaals: Let's break now, and reconvene at 11. We'll be in Salon 5 meeting with Device API. 18:23:50 Travis has left #webapps 18:29:33 Lachy has joined #webapps 18:40:16 johnnyg has joined #webapps 18:54:19 johnnyg has joined #webapps 19:01:15 tlr_ has joined #webapps 19:02:46 arun has joined #webapps 19:03:20 darobin has joined #webapps 19:05:07 johnnyg has joined #webapps 19:06:19 mjs has joined #webapps 19:06:35 weinig has joined #webapps 19:06:51 shiki has joined #webapps 19:07:19 pererik has joined #webapps 19:07:51 jorlow has joined #webapps 19:08:02 Vladimir has joined #webapps 19:08:43 shepazu has joined #webapps 19:10:03 jorlow has joined #webapps 19:10:13 sicking has joined #webapps 19:10:14 rrsagent, make logs public 19:10:19 rrsagent, draft minutes 19:10:19 I have made the request to generate http://www.w3.org/2009/11/02-webapps-minutes.html chaals 19:10:33 rrsagent, this meeting crosses midnight 19:10:33 I'm logging. I don't understand 'this meeting crosses midnight', chaals. Try /msg RRSAgent help 19:11:14 rrsagent, this meeting spans midnight 19:11:33 jorlow_ has joined #webapps 19:13:31 Zakim has left #webapps 19:14:40 Vagner-br has joined #webapps 19:22:38 tlr__ has joined #webapps 19:22:59 Marcos has joined #webapps 19:24:49 tlr has joined #webapps 19:43:03 gsnedders has joined #webapps 19:47:04 Vagner-br has left #webapps 19:48:10 mmielke has joined #webapps 19:53:38 NEWTON_VAGNER_DIN has joined #webapps 20:04:32 mmani has joined #webapps 20:05:02 smaug has joined #webapps 20:07:41 Hixie has joined #webapps 20:09:50 JonathanJ has joined #webapps 20:25:36 timeless_mbp has joined #webapps 20:29:15 pererik has joined #webapps 20:51:21 Marcos has joined #webapps 20:51:45 jorlow_ has joined #webapps 20:52:12 Marcos has joined #webapps 21:38:50 timeless_mbp has joined #webapps 21:46:00 Marcos has joined #webapps 21:46:15 shiki has joined #webapps 21:48:30 shepazu has joined #webapps 21:50:36 weinig has joined #webapps 21:51:39 pererik has joined #webapps 21:53:28 mjs has joined #webapps 21:54:34 NEWTON_VAGNER_DIN has joined #webapps 21:59:13 sicking has joined #webapps 22:00:57 ArtB has joined #webapps 22:01:36 pererik has joined #webapps 22:01:50 darobin has joined #webapps 22:01:55 plh has joined #webapps 22:02:08 Vladimir has joined #webapps 22:02:09 ArtB has changed the topic to: WebApps agenda Nov 2: http://www.w3.org/2008/webapps/wiki/TPAC2009APIs#Monday.2C_November_2 22:02:33 chaals has joined #webapps 22:02:40 RRSAgent, pointer 22:02:40 See http://www.w3.org/2009/11/02-webapps-irc#T22-02-40 22:03:13 RRSAgent, make minutes 22:03:13 I have made the request to generate http://www.w3.org/2009/11/02-webapps-minutes.html ArtB 22:03:23 Scribe: Chaals 22:03:33 ScribeNick: chaals 22:03:40 Topic: CORS 22:04:44 Marcos has joined #webapps 22:05:11 Present+ ArtB 22:05:27 timeless_mbp has joined #webapps 22:05:55 AvK: Two open issues raised by mnot 22:06:20 ... one is naming, one is technical. And a missing issue MM is here to talk about - should we throw it all away... 22:06:57 MM: Suggesting the mechanism should not present authorising information in a ?? fashion. It's up to applications to decide what to do 22:07:03 DanC has joined #webapps 22:07:14 AvK: Also status of origins spec at IETF, and call for tutorials/use cases. 22:07:20 Magnus has joined #webapps 22:07:34 ... let's begin with the big fat guy in the middle of the room 22:08:54 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. 22:09:27 ... CORS links origin of requester from origin header, which fulfils requirements to make Confused Deputy problems. 22:09:39 ... discussion hasn't addressed the objection. 22:09:54 ... Not showed that it doesn't apply, doesn't matter, etc. 22:09:55 q+ to ask about a sample attack... 22:10:15 ack arun 22:10:24 q+ 22:10:26 tlr has joined #webapps 22:10:32 q+ tyler 22:10:48 AR: Can anyone show a sample attack that demonstrates the nature of the problem? 22:11:15 MM: Tyler Close posted a 3-aparty interaction where each step is intuitive in CORS< and the result creates a confused deputy problem. 22:11:20 ack mjs 22:11:20 adrianba has joined #webapps 22:11:28 jorlow has joined #webapps 22:11:51 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 22:12:05 MM: What validation should the second party do to the URIs to ensure control? 22:12:22 MJS: Site 1 has photos, site 2 printing, site 3 has storage. 22:12:35 ... photo site wants printer to get things from storage. 22:12:42 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1324.html is Tyler's example 22:12:42 example from Tyler: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1324.html 22:12:49 ... etc. 22:12:52 q+ 22:13:19 ht has joined #webapps 22:13:20 ... 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. 22:13:38 TC: That is right, but you don't need CORS to do it 22:13:46 NEWTON_VAGNER_DIN has joined #webapps 22:13:54 MJS: How do you do it without server-server comms which is a goal of CORS 22:14:02 ArtB -- TAG is coming, unless you say no. . . 22:14:10 chaals, some TAG members will be joining in a minute 22:14:19 soonho has joined #webapps 22:14:42 This is Tyler's Email: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1324.html 22:15:18 Qiuling has joined #webapps 22:15:42 TC: We know in principle that using client authentication is vulnerable to CD. We have experienced this on the web - csrf, clickjacking. 22:15:57 ... CORS proposes another way to use client auth on the web. 22:16:03 q+ to ask if we are worried about malicious or accidental problems 22:16:15 q? 22:16:26 ArtB has joined #webapps 22:16:32 Zakim has joined #webapps 22:16:53 DS: It seemed that the attacks are not malicious, but accidental. Ambient authority gets wrong access. 22:17:30 MM: My sense was that it is not accidental. The program issuing a command could, I think maliciously, "mis"direct information 22:18:05 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. 22:18:17 MJS: CSRF lets people set up malicious attack 22:18:31 MM: I am happy that if we can solve the malicious cases we are fine. 22:18:56 TC explains his email example with a drawing. 22:19:04 original confused deputy description: http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html 22:20:14 MJS: I think that this setup requires a shared secret, which requires server-server communication. 22:20:23 Present+ TAG 22:22:07 DanC has joined #webapps 22:22:25 johnnyg has joined #webapps 22:22:41 q? 22:22:42 mmielke has joined #webapps 22:22:46 noahm has joined #Webapps 22:23:12 RRSAgent, poinger? 22:23:12 I'm logging. Sorry, nothing found for 'poinger' 22:23:14 RRSAgent, pointer? 22:23:14 See http://www.w3.org/2009/11/02-webapps-irc#T22-23-14 22:23:29 TC: 3 servers. 1 has photos, 2 is a printer, 3 is a storage service 22:23:33 htt has joined #webapps 22:23:35 Marcos has joined #webapps 22:23:40 mmielke has joined #webapps 22:24:20 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 22:24:37 somebody who has a camera should please take a photo of Tyler's diagram 22:25:23 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 22:25:39 (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) 22:25:42 MM: The key is that post-login the auth login is not ambient 22:25:45 q+ rob 22:26:15 MJS: Main reason for CORS is to bootstrap the one-time mechanism - only other known ways are shared secret on server side and require server-server communication to pass the tokens 22:26:23 s/ways/way/ 22:26:59 ... (server can't send its secret via the client, because then it isn't secret) 22:27:22 JonathanJ has joined #webapps 22:27:35 DS: Is the data otherwise secure? 22:27:39 TC: Yes. 22:28:01 (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.) 22:28:04 ack rob 22:28:36 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. 22:28:49 mmani has joined #webapps 22:28:56 MM: You are not an origin... 22:29:10 MJS: You can make a request, but you can't guarantee that it gets fulfilled 22:29:29 q? 22:29:30 timeless_mbp has joined #webapps 22:30:14 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 22:31:37 (the security risks are clear enough to me; have alternative designs that avoid the risks been offered?) 22:32:10 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. 22:32:57 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. 22:33:40 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. 22:33:44 (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.) 22:33:54 +1 22:34:19 DanC, there is no issue number 22:34:27 yeah, that seems like a bug 22:34:28 ... CORS lets you solve this by giving a secure mechanism for dealing with the transaction. 22:34:28 q+ raman 22:34:32 Marcos has joined #webapps 22:34:43 easy to fix: ISSUE: confused deputy problem 22:34:50 DanC, if we agree this is an issue there's no need for an issue number because we'd need to do something else 22:34:59 TC: Web browser is on a site that cmes from the photo manager. all interactions take place on that page. 22:35:13 anne, not at all. 22:35:41 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. 22:35:42 ... user hits a button to print a photo. a button asks a printer site to print a photo. 22:35:44 an issue is just a promise to make a decision; it doesn't presume which way the decision will go 22:36:34 ACTION: chaals to raise an issue for this question 22:36:34 Created ACTION-432 - Raise an issue for this question [on Charles McCathieNevile - due 2009-11-09]. 22:36:54 action-432? 22:36:54 ACTION-432 -- Charles McCathieNevile to raise an issue for this question -- due 2009-11-09 -- OPEN 22:36:54 http://www.w3.org/2008/webapps/track/actions/432 22:37:00 DanC, fair enough http://www.w3.org/2008/webapps/track/issues/108 22:37:09 close ACTION-432 22:37:09 ACTION-432 Raise an issue for this question closed 22:37:18 Kai has joined #webapps 22:37:26 :) issue-108. thanks. 22:37:28 ht, I will change that now 22:38:01 IH: How does the manager authorise printing? 22:38:07 2.. 22:38:22 TC: Out of band, they made an agreement that the manager could ship jobs to the printer. 22:38:29 arun has joined #webapps 22:40:17 MJS: THe question is whether there is a sensible way to use CORS that doesn't have a vulnerability? 22:40:36 CMN: I think the question is whether there is an obvious way to use CORS that introduces a security risk 22:40:56 TC: We are objecting to the idea that the group is baking up a way that people will create security risks 22:41:14 MJS: I don't think that is an issue. CORS allows for 2-party transactions to be done that are secure. 22:42:22 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. 22:43:31 noahm has joined #Webapps 22:43:33 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? 22:44:06 [back to the example] 22:44:21 issue-108? 22:44:21 ISSUE-108 -- confused deputy problem -- RAISED 22:44:21 http://www.w3.org/2008/webapps/track/issues/108 22:44:41 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. 22:44:55 DanC has joined #webapps 22:45:54 RRSAgent, make minutes 22:45:54 I have made the request to generate http://www.w3.org/2009/11/02-webapps-minutes.html MikeSmith 22:46:06 ... 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. 22:46:32 MM: Intuitive assumption for the developer is that the URL from teh printer site is a URLthe printer has access to. 22:46:59 ... problem arises because if the storage site checks access against the origin, it will check against the manager's access, not the printer's. 22:47:14 ... manager would want to make the decision based on whether the printer has access, but has no way to ask that. 22:47:55 TC: There is an access control problem. CORS is telling developers to use a solution that won't work. There are other solutions. 22:48:19 Rob: If manager was only talking direct to the client, direct to the printer, and direct to the store, no problem. 22:48:48 AR: The use case can be shoe-horned into other systems. 22:49:23 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. 22:49:41 DS: MM agreed there are ways to build secure applications with CORS< as well as building vulnerabilities. 22:49:47 MM: True. 22:49:53 q+ 22:50:01 q- raman 22:50:16 q+ Tyler 22:50:52 oh hey Zakim is back 22:50:55 q+ 22:51:11 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. 22:52:32 CMN: If you can restrict the system to 2 servers, can you avoid the problem. 22:52:45 TC: No. You can still make the problem without the 3rd website. 22:53:06 ... e.g. combine the storage and manager here 22:53:27 IH: Why would the manager give the printer access to tell it to write something over closed content? 22:53:47 q+ 22:53:49 MJS: it seems in the 2-party case you have to make it needlessly complicated to make the vulnerability work 22:53:51 ack chaals 22:54:12 q+ rob 22:54:14 TC: If any auth data from site A came from site B, you create confused authority. 22:54:45 MM: If you are not using anything that didn't come from *you*, then you are not creating a vulnerability. 22:55:21 q+ 22:55:30 ack ty 22:56:13 TC: If you can say "don't apply my authority to anything I didn't make myself" you solve the problem. 22:56:15 ack mj 22:56:50 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. 22:57:08 ... so any request using info from a 3rd party exposes this. 22:57:13 TC: Yes 22:57:21 MJS: Self to self has client authority 22:57:31 TC: Yes, but we should be trying to reduce this. 22:57:58 MM: Guest XHR should not present auth even when it goes back to its own origin. 22:58:07 Present+ timeless 22:58:49 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. 22:59:04 timeless has joined #webapps 22:59:24 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. 22:59:45 q? 22:59:52 ... guestXHR is a refolrmulation of CORS that addresses our security concerns. 23:00:08 a/folrm/form/ 23:00:23 JS: Do you have an alternate proposal. If GuestXHR is it, how do you build a website that uses it nicely? 23:00:40 ... imagine websites would be hesitatnt to ask users to copy strings from one place to another 23:00:52 s/hesitat/hesita/ 23:01:11 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. 23:01:40 MJS: Think the 2-site mechanism is the thing we are interested in. 23:02:07 ack sicking 23:03:17 TC: Would like to see the problem being laid out for existing approach, and I will explain how to fix it 23:03:34 ACTION: jonas write a very concrete example of a problem 23:03:34 Created ACTION-433 - Write a very concrete example of a problem [on Jonas Sicking - due 2009-11-09]. 23:03:47 ACTION: Tyler to explain how to do it with guestXHR in a nice UI 23:03:47 Sorry, couldn't find user - Tyler 23:04:00 mjs' example: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0350.html 23:04:25 ack rob 23:05:07 Rob: Fundamental problem is if manager can be asked to do something by another party, with the authority of the user in the middle. 23:05:15 ... question is whether CORS encourages that behaviour 23:05:18 [+1] 23:05:34 +1 to "are people encouraged" as the key question 23:05:48 ... I am not convinced we are encouraging this behavious with CORS. Are we making it any more likely? 23:05:54 s/vous/vour/ 23:06:05 MM: Problem is not encouraging lack of checking, problem is creating a demand for checking that cannot actually be met. 23:06:19 ... if authority is carried along then there is no problem. 23:06:56 ... Existence of CORS doesn't force servers to make decisions based on origin. If servers make the decision based on extra information carried alongside. 23:07:21 Rob: CORS doesn't create the vulnerability, it creates a communication path. 23:07:41 MM: Creates an conditional path. if it were unconditional there wouldn't be a problem. 23:07:46 AvK: It needs to be conditional 23:07:55 MM: And therefore it is inherently an access control problem. 23:08:21 AR: zakim, close the queue 23:08:28 zakim, close the queue 23:08:28 ok, chaals, the speaker queue is closed 23:08:30 Kangchan has joined #webapps 23:08:48 q+ 23:09:13 Kangchan has left #webapps 23:09:15 AR: 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. 23:09:28 ... there is some case to draw these examples and explain them as bad design. 23:09:53 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. 23:10:13 DS: Let's say we keep it as is, and describe carefully how it should not be used and explain the problems. 23:10:32 ... nobody wants to create insecure interfaces. Can we show them why not to do A, and why to do B instead, would that work? 23:10:49 zakim, open queue 23:10:49 ok, chaals, the speaker queue is open 23:10:52 q+ tlr 23:10:55 zakim, close queue 23:10:55 ok, chaals, the speaker queue is closed 23:10:59 ack arun 23:11:01 MM: yes... 23:11:23 ... point is to enable people to write applications that are useful and secure, and that requires education, any solution we have will require that. 23:12:16 ... 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. 23:12:33 DS: There are inherent composition problems. Can we forestall those in practice? 23:13:48 q+ 23:13:59 awww 23:14:10 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. 23:16:24 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. 23:17:06 ... 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. 23:18:26 CMN: We will wrap here, because we are not getting to resolution 23:18:40 ... will look for more time to do this tomorrow 23:19:01 DS: Can people try to prepare clear presentations for tomorrow? 23:19:13 AvK: Would be good if they can be very concrete. 23:19:34 MM: Didn't see in the draft that a requirement is to avoid server-server communication... is that an understood requirement? 23:19:39 AvK: Yes... 23:20:54 mmani has joined #webapps 23:27:06 Marcos has joined #webapps 23:27:17 johnnyg has joined #webapps 23:35:36 ArtB has joined #webapps 23:35:41 darobin has joined #webapps 23:37:13 Magnus has joined #webapps 23:39:03 Magnus has left #webapps 23:39:11 weinig has joined #webapps 23:39:15 Kai has joined #webapps 23:39:55 Scribe: Sam 23:39:59 Topic: Views 23:40:15 ScribeNick: weinig 23:41:02 anne: there are a bunch of spec that refer to views 23:41:15 anne: rendered view/default view 23:41:29 anne: in reality, all implementations always return the default views 23:41:36 anne: we should kill the concept of views 23:41:50 shepazu: inventor of views thinks it was a bad idea 23:42:09 jonas: mozilla has support but it is a pain in the buttox 23:42:36 shepazu: does anyone know of any implementations 23:43:01 jonas: mozilla uses if for print preview, but it is not accessible from the dom 23:44:08 maciej: concept of views seems unnecessary, but there APIs we need to keep (AbstractView, etc) 23:44:37 maciej: getComputedStyle 23:44:53 anne: we should keep the APIs, but get rid of the concept 23:45:26 anne: offsetLeft, etc, will all be relative to the one true view now 23:45:49 shepazu: I agree completely 23:48:09 [discussion of details about which specs and how we organise them] 23:48:56 maciej: UI events need a view 23:49:44 RESOLUTION: Remove concept of views 23:50:22 MikeSmith: what about DOM Level 2? 23:50:38 chaals: we should issue an erratum 23:51:00 Paul: we can issue a note on the existing spec 23:51:21 Paul: for the TR page 23:51:54 chaals: we want to point out that there is an "untruth" in the DOM Level 2 spec which people are reading 23:52:42 SW: I implemented some stuff in CSSOM for fun, and we found that CaretRangeForPoint is less useful than we would like 23:52:51 s/For/fROM/ 23:53:21 ... 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. 23:53:36 ... Use case was dictionary popup - want to know what word you are over. 23:53:42 DS: Ditto in IMEs 23:54:12 AvK: Maciej proposed to change to CaretPositionFrom Point, which is an offset integer from the current node (number of characters...) 23:55:18 chaals: in the case where the parent is an element, it can be an awkward API 23:55:25 dom has joined #webapps 23:55:29 s/chaals/maciej/ 23:55:32 eek 23:55:33 ACTION: ArtB to notify Widgets WG that they have 2 weeks to review WARP 23:55:33 Created ACTION-434 - Notify Widgets WG that they have 2 weeks to review WARP [on Arthur Barstow - due 2009-11-09]. 23:55:53 pererik has joined #webapps 23:56:18 maciej: there is no way to know all the of the names of the form controls 23:56:50 tl: can css change things into form controls 23:57:04 maciej: there is css-appearance 23:57:15 maciej: there is svg:textarea 23:57:33 anne: that has ranges inside it if is editable 23:59:16 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 23:59:29 johnnyg_ has joined #webapps 23:59:52 maciej: 2) if you hit a form control, the container is the control, the offset is the offset in the control 00:00:37 SW: With range ability to get position you can get a bounding box of the collapsed range 00:01:01 maciej: 3) if you hit an element, you get the element as the container, the offset is the range offset 00:01:35 anne: the caretPosition object should have a range attribute, which is null for form controls 00:03:16 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? 00:03:50 anne: dean (apple) asked me about that, people from apple have been asking me about it as well 00:05:05 maciej: returning the bounding box seems like the most sensible thing 00:05:23 jonas: that is what is done for svg 00:05:40 maciej: but we should have quad apis as well 00:05:59 maciej: maybe we only need 3 points, maybe we want 4 for perspective transforms 00:06:09 maciej: math is hard 00:06:18 Nikunj has joined #webapps 00:06:39 s/jonas/anne/ 00:06:42 johnnyg has joined #webapps 00:07:36 Marcos has joined #webapps 00:08:16 Travis has joined #webapps 00:08:55 maciej: all we really need is a way to take the bounding box and convert it page space 00:09:16 http://www.w3.org/TR/2009/WD-css3-2d-transforms-20090320/#dom-interfaces 00:09:53 tlr has joined #webapps 00:09:58 maciej: we need a way to convert a point from node to page space (and vice-versa) as well 00:10:08 anne: what is the coordinate system of the node 00:10:22 chaals: it is the point in the transformed node 00:10:29 chaals does something with his hands 00:10:46 zakim, open queue 00:10:46 ok, chaals, the speaker queue is open 00:11:09 Nikunj1 has joined #webapps 00:11:40 anne: we should probably try and move these apis away from the window if we can 00:12:07 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 00:12:22 arve has joined #webapps 00:13:06 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 00:13:27 adjourned 00:13:29 adjourned 00:13:54 s/adjourned/in recess/ 00:13:59 s/adjourned/in recess/ 00:22:59 soonho has joined #webapps 00:23:00 Marcos has joined #webapps 00:33:33 timeless_mbp has joined #webapps 00:34:12 Kai has joined #webapps 00:38:32 Nikunj has joined #webapps 00:40:57 Marcos has joined #webapps 00:40:59 ArtB has joined #webapps 00:52:52 shepazu has joined #webapps 00:54:26 soonho has left #webapps 00:58:01 shepazu has joined #webapps 01:01:35 Scribe: Maciej 01:01:38 avk: ISSUE-33 - should re-entrance be allowed for readystatechange 01:01:45 ScribeNick: mjs 01:01:50 ISSUE-33 01:02:14 js: so are you not allowed to call open? does that throw an exception? 01:02:18 avk: in IE yes 01:02:19 trackbot, start telcon 01:02:21 RRSAgent, make logs public 01:02:23 Zakim, this will be WAPP 01:02:23 I do not see a conference matching that name scheduled within the next hour, trackbot 01:02:24 Meeting: Web Applications Working Group Teleconference 01:02:24 Date: 02 November 2009 01:02:43 ISSUE-33? 01:02:43 ISSUE-33 -- Shoulld re-entrance be allowed foronreadystatechange? -- OPEN 01:02:43 http://www.w3.org/2008/webapps/track/issues/33 01:02:44 tl: if you open from a readystatechange handler on the same object? 01:02:48 js: yes: 01:02:53 tl: I don't know what IE does 01:03:35 avk: other browsers allow it, and restricting it would be weird 01:03:46 tl; sounds like it's a synchronous event allowing re-entrancy 01:04:02 js: my recollection is it was more a concern with later readystates like 3 or 4 01:04:31 js: I know we just allow anything anywhere, I don't remember what IE does 01:05:19 ACTION: travis To research what IE does for readystate re-entry (for ISSUE-33) 01:05:19 Created ACTION-436 - Research what IE does for readystate re-entry (for ISSUE-33) [on Travis Leithead - due 2009-11-10]. 01:05:40 sw: I think readystatechange is async 01:05:43 js: not always 01:07:03 avk: (explains details) 01:09:14 ISSUE-103 01:09:33 ISSUE-103? 01:09:33 ISSUE-103 -- accessing status/statusText/getResponseHeader()/getAllResponseHeaders() -- RAISED 01:09:33 http://www.w3.org/2008/webapps/track/issues/103 01:09:49 avk: the issue is that IE throws when certain methods are called in a particular state 01:11:43 avk: not throwing is generally better 01:11:51 tl: unless there's a really good reason to throw 01:13:44 js: it appears Firefox never throws for status but it might throw more often for statusText 01:13:57 js: appears to throw a random number 01:15:07 sw: we added throwing to match other browsers (the minimum) 01:15:23 js: why did you change, was it b/c websites complained? 01:15:54 sw: I don't remember, it might have been to change the spec 01:16:10 *general mumbling* 01:16:17 *awkward silence* 01:16:26 ... 01:17:34 avk: what are we going to do - change and not throw? 01:18:29 js: I'd like to err on the side of not throwing 01:19:12 RESOLUTION: for ISSUE-103, don't throw 01:19:39 the other bit for XHR1 was the test suite 01:19:43 ^ avk: 01:19:50 avk: it would be nice to have some help at some point 01:19:58 fo: I've got some notes which I still owe you on that 01:20:10 jr: do you have mark nottingham's tests? do they cover different things? 01:20:16 avk: probably 01:20:21 jr: I think he's got things checking caching 01:21:10 avk: the test suite has quite a lot of coverage, especially security stuff and resolving URLs 01:21:17 avk: there's definitely more things that can be tested 01:21:22 cmn: which things are those 01:21:33 avk: methods probably... http verbs 01:21:52 avk: there's a bunch of side effects that are not all covered yet, e.g. when you invoke open() 01:22:02 avk: *more technobabble about complicated steps* 01:22:23 avk: I don't think there's tests for Accept, Accept-Language, conditional GET 01:23:47 mjs: are the tests in cvs? 01:23:50 http://tc.labs.opera.com/apis/XMLHttpRequest/ 01:23:51 avk: not currently 01:23:53 http://tc.labs.opera.com/svn/ 01:24:39 avk: I don't really like working on tests 01:24:50 ds: Anne, what's your job title? 01:24:54 avk: I work on specs! 01:25:34 cmn: any volunteers to write tests? 01:25:59 johnnyg has joined #webapps 01:26:03 Scribe: Nikunj 01:26:18 avk: Starting on XHR2 01:26:22 Topic: XHR2 01:26:34 Issue 104? 01:26:50 No serialization defined for structured clones 01:27:04 avk: Use multi-part MIME for structured clones 01:27:10 ack: may be JSON support at some time 01:27:20 ISSUE-104? 01:27:20 ISSUE-104 -- supporting structured clones -- RAISED 01:27:20 http://www.w3.org/2008/webapps/track/issues/104 01:27:23 s/ack:/avk/ 01:28:02 avk: Close 104 for now and revisit when we have a serialization format 01:28:17 avk: structured clones can include certain data types beyond JSON 01:28:25 avk: such as images and files 01:28:48 mw: used for local storage, and others 01:28:59 avk: used also in post message 01:29:31 avk: waiting until file API to add file upload 01:29:46 avk: also waiting to append file blobs 01:29:58 avk: browser would send multipart form-data when you do send 01:30:05 avk: similar to raw html forms no 01:30:20 avk: if we can support this API then we don't need a FileList in the API 01:30:30 avk: could be Jeremy Orlow 01:31:40 avk: append files or strings on formdata object 01:31:50 so that we don't need a method on XHR 01:32:18 avk: its been requested to serialize an html form and pass it to XHR 01:32:29 avk: so you can asynchronously upload it 01:32:38 avk: others requested - blob 01:32:49 avk: WebKit supports FileList 01:33:04 ar: File is supported in Mozilla 01:33:16 sw: WebKit also supports a single File 01:33:25 jonas: do you send the file name anywhere? 01:33:30 avk: no 01:33:32 sw: no 01:33:36 avk: how would you? 01:33:42 jonas: use some kind of header 01:33:48 avk: authors can add a headers 01:33:54 sw: we don't 01:34:10 arun: send a blob and a hypothetical object 01:34:36 avk: send would be extended to accept Blob and FormData 01:34:42 where FormData = hypothetical object 01:34:53 avk: For FormData, the UA would set the content-type header if the author did not set it 01:35:17 arun: Is Hixie writing FormData? 01:35:25 avk: No I will do it - a small edit 01:35:40 arun: FormData append would accept a Blob? 01:35:43 avk: It would 01:36:02 avk: It seems that this would address several requests 01:36:17 arun: It seems to - a requirement that was not adequately addressed by FileAPI 01:36:53 avk: MS has a proprietary extension exposed to VBScript called ResponseBody that returns a byte array or byte stream 01:37:04 avk: we could use it or rename it to ResponseBlob 01:37:10 avk: Unless MS cares for it 01:37:18 adrian: we would like to carry on using it 01:37:31 mjs: It should not be a blob, but rather a byte array 01:37:59 mjs: Blob offers only async, and if the data is already loaded then array is better 01:38:06 mjs: should not do another async 01:38:22 jonas: only thing is if you are loading a big thing, then ua will be forced to keep it in memory 01:38:36 mjs: if loading something bigger than address space, then store it 01:38:49 jonas: not looking for large streams 01:39:42 mjs: ideally ua should download large files through streaming model 01:39:57 mjs: assuming its a file object stream to a file 01:40:09 avk: and then access the file 01:40:18 avk: responseText already loads in to memory 01:40:28 mjs: turn off storing in memory if its large 01:40:46 avk: need ECMA to figure out a binary type array 01:40:54 avk: should not be that hard - like image data 01:41:00 mjs: easy to make complicated 01:41:19 mjs: if its immutable, then it is easy to use the raw bytes as backing store 01:41:30 mjs: no thread safety issue even if passed to workers 01:41:42 mjs: immutable is harder to modify 01:41:59 mjs: most APIs make two versions of APIs available - mutable and not 01:42:06 avk: ImageData is immutable 01:42:13 mjs: backing store is canvas 01:42:40 jonas: byte array building API might be a good way to mutate ResponseBlob 01:42:49 jonas: look forward to mjs' proposal 01:43:09 avk: response thing and new things for sending out are new items 01:43:27 avk: timeout proposal is also new 01:43:36 avk: ontimeout listener for milliseconds timeout 01:43:49 avk: if the server doesn't respond, then do the abort thing and dispatch timeout event 01:43:55 avk: timeout needs to be sorted out 01:44:20 jonas: two arguments - sync XHR doesn't allow timeout 01:44:32 jonas: not allowing timeout doesn't preclude users from using it 01:44:39 avk: use workers 01:44:53 jonas: provide timeouts so that user experience is slightly better 01:44:59 avk: are you providing them? 01:45:01 jonas: yes 01:45:14 avk: timeouts are something that you should certainly have 01:45:27 jonas: almost everyone using XHR uses it anyway, so provide a convenience function 01:45:38 jonas: MS added it to XDR? 01:45:41 adrian: yes 01:45:48 sam: is it a default or an attribute? 01:45:53 adrian: attribute 01:45:59 avk: what does it do on getting? 01:46:08 jonas: its a set only 01:46:14 avk: does such a thing exist? 01:46:27 travis: doing a quick test 01:46:32 jonas: what's a good default value 01:46:39 travis: or do you timeout at all 01:46:52 adrian: if not set, it doesn't 01:46:59 adrian: so the behavior is not changed 01:47:13 adrian: XHR also has the like named attribute 01:47:34 jonas: very inclined to add the attribute to XHR2 spec 01:47:54 Travis has joined #webapps 01:48:01 sam: concern - putting in the hands of the user, what is the stall for the ua? 01:48:08 sam: 10 ms is OK or 100 is OK? 01:48:14 sam: in the past any amount was OK 01:48:20 Reading IE's timeout property (before setting) returns -1. 01:49:13 avk: testing in different conditions, like a slow network, may find odd behavior but the other person in a good one doesn't 01:49:40 adrian: common use cases are sites doing click tracking, trying to capture when someone clicked a link 01:50:01 adrian: OK with losing data when a request is not fired in the timeout 01:50:20 adrian: here's a request to make and if the request doesn't respond we give up 01:50:36 avk: better option available - html5 ping attribute 01:51:11 adrian: there are other issues being raised, that make the option controversial and this WG is not the right forum to discuss 01:51:22 avk: not opposed to adding it, concerned that it will be abused 01:51:27 jonas: in what way? 01:51:31 avk: use sync more 01:51:48 jonas: what will help most is a test suite guide 01:52:02 jonas: go through the spec and not follow it closely, although well followed, 01:52:14 jonas: edge cases are where we differ, otherwise everyone is close 01:52:22 avk: but that makes it look pretty broken 01:52:41 jonas: not material adding new features to newer versions to getting bugs fixed 01:53:14 avk: explicit constructor for XO requests 01:53:24 jonas: that conversation is sort of CORS-existential one 01:53:28 avk: agreed 01:53:56 jonas: interesting idea to have a totally anonymous XHR object, both for X-S and S-S request 01:54:20 travis: which is XDR 01:54:25 jonas: but that sends Origin 01:55:16 avk: proposed resolution on timeouts for XHR2 01:55:26 avk: to add 01:56:12 nikunj: would we do it to file? 01:56:17 ArtB has joined #webapps 01:56:21 jonas: not required to follow a single style in general 01:56:29 jonas: hesitant to draw a connection? 01:56:45 adrian: a case to be made for XHR things to be repeated elsewhere 01:56:51 adrian: timeout is not one of those things 01:57:03 adrian: network requests cause timeouts to matter 01:57:25 adrian: it seems less likely to need them for files 01:57:34 jonas: much less likely for a file request to time out 01:57:47 sam: network files time out 01:57:50 adrian: edge case 01:58:08 avk: also need resolution on FormData 01:58:17 jonas: iffy about that 01:58:36 jonas: seems weird to create a new object for creating an object only to send to another one 01:58:42 avk: not ugly, can reuse it 01:58:49 sam: websockets may also want to do it 01:58:52 jonas: really? 01:58:58 everyone: laughing loud 01:59:13 chaals: consensus? 01:59:23 sam: I don't object, not excited 01:59:33 jonas: it helps to abort a connection if it takes too long 01:59:46 sam: agreed, but not a strong enough reason because that might be only one of the ways to do it 01:59:56 jonas: could use setTimeout 02:00:08 jonas: risk that people may use sync XHR more 02:00:18 jonas: we fired timeouts during syncXHR 02:00:24 jonas: fallback was to wait longer 02:00:30 jonas: not ideal 02:00:46 jonas: some people may never switch away from sync XHR? 02:00:59 adrian: we shipped timeouts 02:01:21 adrian: good idea 02:01:40 chaals: any objections? 02:01:47 sam: risks in either direction 02:02:04 adrian: also supported for sync XHR 02:02:14 RESOLUTION: Anne to put timeout attribute in XHR 02:02:34 avk: Proposal to overload send for Blob objects 02:02:49 avk: FormData contains a constructor and accepts either Blob or DOMString 02:03:02 which serializes as multipart/form-data 02:03:17 sam: support strongly Send Blob with File 02:03:32 sam: other one need to see a proposal and remove it if that looks terrible 02:03:40 jonas: feels same way 02:03:40 http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0244.html 02:04:12 RESOLUTION: Copy and paste this into the proposal on FormData and Blobs 02:04:47 jonas: like to implement streaming 02:05:58 jonas: 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 02:06:06 avk: can we use server sent events? 02:06:17 jonas: this is not for that, but for large files 02:06:34 jonas: its started from server sent events, but different 02:06:42 avk: use cases are required 02:06:55 chaals: good proposal not quite a finished 02:07:25 chaals: need a meatier proposal 02:07:28 jonas: would do 02:07:37 chaals: how far from XHR? 02:07:53 avk: ask jonas, sam, and adrian 02:08:03 avk: if everyone finishes implementation, then we are done 02:08:19 jonas: start writing test cases 02:08:34 adrian: take it first to LC, then the test suites will happen before CR 02:08:57 avk: ISSUE-33 needs to be resolved first 02:09:10 travis: it is already re-entrant 02:09:15 chaals: so we can close the issue? 02:09:35 jonas: can we go to LC? 02:09:42 chaals: we need a formal vote 02:09:49 avk: need to edit the spec first 02:10:18 RESOLUTION: Close ISSUE-33 because everyone is re-entrant 02:10:47 chaals: should we take anne's draft to LC? 02:11:01 avk: this is the third LC 02:11:15 chaals: RESOLUTION: XHR goes to Last Call 02:11:40 chaals: meeting is adjourned 02:13:32 rrsagent, draft minutes 02:13:32 I have made the request to generate http://www.w3.org/2009/11/02-webapps-minutes.html chaals 02:13:35 jorlow has joined #webapps 02:17:22 Marcos has joined #webapps 02:19:02 shiki has left #webapps 02:20:54 anne has left #webapps 03:16:20 Zakim has left #webapps 03:19:07 Nikunj has joined #webapps 03:38:42 mmielke has joined #webapps 03:44:02 arun has joined #webapps 03:52:08 mmielke has joined #webapps 03:59:09 sicking has joined #webapps 04:01:42 jorlow has joined #webapps 04:07:24 jorlow has joined #webapps 04:31:39 Nikunj has joined #webapps 04:42:49 jorlow_ has joined #webapps 04:43:19 mjs has joined #webapps 05:27:50 jorlow has joined #webapps 05:53:30 jorlow_ has joined #webapps 06:07:47 johnnyg has joined #webapps 06:37:54 Marcos has joined #webapps 06:42:57 DanC has joined #webapps 06:50:42 timeless_mbp has joined #webapps 06:58:56 hober has joined #webapps 07:11:25 shepazu has joined #webapps 07:25:38 arve has joined #webapps 07:28:16 weinig has joined #webapps 07:35:08 Marcos has joined #webapps 08:25:44 Nikunj1 has joined #webapps 08:59:26 Nikunj has joined #webapps 12:04:14 smaug_ has joined #webapps 12:58:34 arun has joined #webapps 13:32:02 annevk has joined #webapps 14:50:54 ArtB has joined #webapps 15:00:48 aroben has joined #webapps 15:02:29 johnnyg has joined #webapps 15:09:28 Nikunj has joined #webapps 15:11:05 noahm has joined #Webapps 15:27:05 shepazu has joined #webapps 15:28:45 mmielke has joined #webapps 15:51:51 Marcos has joined #webapps 16:09:29 Marcos has joined #webapps 16:10:20 tlr has joined #webapps 16:24:57 weinig has joined #webapps 16:31:25 ArtB has joined #webapps 16:34:06 dom has left #webapps 16:35:39 AdamB has joined #webapps 16:37:00 soonho has joined #webapps 16:37:13 soonho has left #webapps 16:37:27 darobin has joined #webapps 16:47:03 mmielke has joined #webapps 16:48:14 shiki has joined #webapps 16:49:21 shiki has joined #webapps 16:53:17 AdamB has joined #webapps 16:53:33 pererik has joined #webapps 16:57:15 timeless_mbp has joined #webapps 16:58:07 AdamB has left #webapps 16:59:28 arve has joined #webapps 17:00:32 chaals has joined #webapps 17:00:49 Zakim has joined #webapps 17:03:09 ArtB has joined #webapps 17:03:30 JonathanJ has joined #webapps 17:05:34 Nikunj has joined #webapps 17:06:08 VagnerW3CBrasil has joined #webapps 17:09:00 sicking has joined #webapps 17:09:23 Marcos has joined #webapps 17:09:38 scribe:sicking 17:09:41 Kai has joined #webapps 17:09:43 scribe:s icking 17:09:49 scribe: sicking 17:10:04 tlr has joined #webapps 17:10:18 [The spec we will discussing is available at http://dev.w3.org/2006/webapi/WebIDL/] 17:10:34 Vladimir has joined #webapps 17:11:10 annevk has joined #webapps 17:11:54 Lachy has joined #webapps 17:11:59 topic: WebIDL yo 17:13:10 AR: Arun 17:13:47 Present: Chaals, Sam, Per Erik, Vladimir, Satoshi, Shiki, Arun, Nikunj, Anne, Rob, Lachlan, Jonas, Travis, Adrian, 17:14:39 SW: introduction about webidl 17:15:02 Travis has joined #webapps 17:16:35 http://dev.w3.org/2006/webapi/WebIDL/ 17:16:40 AR: there's some things that are still left loose, we should define those stricter 17:16:52 SW: ok, got specific issues? 17:17:04 AR: how are exceptions done? 17:17:18 AR: missing primitives like ByteArray 17:17:30 SW: have to check spec re exceptions 17:17:45 SW: re bytearray, it's a question of scope 17:18:35 SW: spec already big. Contains gramar, some basic primitives like getters/setters/stringifyers, also some types and extended attributes 17:18:48 SW: sequences would be useful 17:19:24 JS: need to define what exactly a seqnece is 17:19:53 SW: sequence is a JS array, array is a host object 17:19:53 howard has joined #webapps 17:19:55 http://dev.w3.org/2006/webapi/WebIDL/#es-sequence 17:20:05 shepazu has joined #webapps 17:20:33 SW: NodeList seems to map closer to array 17:20:57 JS: NodeList is readonly, so can't be a simple JS-array 17:21:33 NM: is anyone actually using Array? 17:21:53 ...crickets... 17:22:42 SW: don't know of any specs that use it. Maybe NodeList could be expressed as an Array 17:23:11 SW: might not be worth putting Array in v1 if no one is using it 17:23:31 howard has joined #webapps 17:23:41 hmm, I think sequence<> needs to map to an object that has item() and length; is that the case? 17:24:15 TL: TC-39 is taking interest 17:24:16 MikeSmith has joined #webapps 17:24:17 well, it would be nice to have a shorthand for NodeList like interfaces 17:24:23 howard has left #webapps 17:24:24 not sure if it needs to be sequence<> 17:24:37 TL: I expressed it to them as an grammar language, and a binding language 17:25:05 TL: they took a lot interest in the binding part 17:25:49 TL: TC-39 expressed interest in owning the JS bindings, claiming they had more expertize 17:26:04 Lachy has joined #webapps 17:26:09 SW: I think the main value of webidl is the bindings, not so much the grammar 17:26:16 TL: agreed 17:26:28 AvK: also value for spec authors 17:26:50 SW: concerned about splitting out bindings 17:27:00 TL: then they should be able to participate 17:27:05 SW: most definitely 17:27:27 Vladimir has joined #webapps 17:28:02 DS: I'm also concerned about splitting it. Splitting things in two leads to overhead and poor coordination 17:28:02 Present+ Maciej 17:28:09 Present+ Doug 17:28:24 Present+ Sicking 17:28:43 RRSAgent, make minutes 17:28:43 I have made the request to generate http://www.w3.org/2009/11/02-webapps-minutes.html MikeSmith 17:28:44 SW: there are things we could split, like deprecated features 17:29:00 arun has joined #webapps 17:29:02 mjs has joined #webapps 17:29:04 annevk, that's how I roll 17:29:27 s/coordination/coordination... I would be happy to have it worked on jointly, if we can do that, and public-script-coord should help 17:29:53 MJS: even such a split is concerning. Similar to how ecmascript leaves host objects largely undefined 17:29:57 SW: agreed 17:30:05 Present+ MikeSmith 17:30:21 MJS: explicitly noting that certain things are deprecated could still be done 17:30:45 Present+ Julian 17:30:53 TL: do we know what we want to mark as deprecated 17:31:05 SW: custom deleters 17:31:18 MJS: also catch-alls in general 17:31:44 MJS: not neccesarily consencus that catchalls are always bad 17:32:14 MJS: separately, seems to be consensus that array-like accessors are ok 17:32:28 AvK: what does "deprecated" even mean? 17:32:50 SW: that a feature shouldn't be used in new interfaces, but is described for legacy reasons 17:33:01 Nikunj has joined #webapps 17:33:45 MJS: multiple inheritance might not be needed by existing browsers 17:33:57 MJS: however SVG uses it 17:34:29 MJS: browsers don't seem to implement SVGs stuff as real multiple inheritance. Simply implemented as separate interfaces 17:35:05 TL: there is a desire from TC-39: don't allow bindings to do things that aren't allowed by ecmascript itself 17:35:22 TL: want to be able to implement DOM in ecmascript 17:36:29 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 17:37:51 TL: want to mark things that will *never* be part of ES as deprecated 17:38:03 SW: how to we determine what will never be part of ES? 17:38:22 MJS: It's very hard. Not even catchalls are for sure never going to be a part of ES 17:38:37 CM: guessing the future is hard 17:39:14 DS: when do we expect webidl to progress to LC and beyond 17:39:29 DS: and all those other fuzzy W3C rules 17:39:34 Lachy has joined #webapps 17:39:50 SW: depends on what people want from spec 17:40:03 SW: it's really a tool for spec authors 17:40:52 MJS: changing the spec to use ES5 formalisms is a big change 17:41:07 TL: ES5 has accessors, rewriting to use those will take work 17:41:43 DS: Robin wanted to publish sooner rather than later 17:42:23 MJS: there's tradeoffs, there's many specs that want to use it 17:43:11 SW: I'm not all that familiar with W3C rules quite yet 17:43:17 DS: This is an unusual spec 17:43:49 DS: the implementations for this spec are other specs 17:44:17 SW: Also testcases. You can produce a lot of tests based only on the idl 17:44:33 SW: Want a tool that given an idl produces tests 17:45:04 SW: browsers are also implementors 17:45:52 DS: sort of circular dependency. Won't know that things worked until another spec has used webidl and that spec got implemented 17:46:51 MJS: we could take a stable spec, such as DOM Core, and express it using webidl 17:47:03 DS: Cameron did that 17:47:30 SW: would come close, but doesn't test everything. Might also want to do for example canvas to test overloading 17:48:21 MJS: should start with dom core and see what coverage that gets us. But yes, canvas would cover a lot of nice things 17:48:48 RE: has anyone does a matematical analysis of webidl? Would that be useful? 17:49:08 SW: don't know. If anyone has done it, cameron has, he loves math. But don't think he has 17:50:24 SW: OMG doesn't define enough things. That's why specs had bindings sections. But even those aren't enough, and might not be normative 17:51:57 SW: changing spec to use ES5 terminology will be a big change, but not a functional change 17:52:35 NM: is it a requirement for going to last call 17:52:54 AvK: doesn't make sense to define things in terms of ES3 if everyone implements ES5 17:53:59 DS: when you make that change, document how you map old terminology to ES5 terminology 17:54:15 SW: good idea 17:54:38 SW: not sure about some features in the spec. One is method overloading 17:54:46 http://dev.w3.org/2006/webapi/WebIDL/#idl-overloading 17:55:06 TL: hard to have an opinion, cause it's hard to understapnd spec 17:55:20 SW: that's part of the problem 17:56:15 AvK: canvas and XHR uses overloading, though in different ways 17:56:49 TL: we have default values for optional arguments 17:57:01 TL: we use it for XHR 17:58:09 SW: when i started on webkit, we had hand-written code that implemented the bindings. We still have a custom IDL 17:58:58 MJS: we currently have one-offs for all overloads. Would like to use webidl to express and implement it instead 18:00:49 JS: not sure we can use idl with overloads directly 18:01:02 MJS: you can use whatever solution you're currently using 18:01:57 MJS: webidl has optional. Limited by that each argument is optional. Can't enforce that either 0 or 2 arguments are provided 18:02:39 MJS: if optional could be in batches, then you could require that the other arguments must differ in type 18:03:14 JS: errors seem to be ambigious 18:05:03 MJS: one problem is that anything that takes a string essentially accepts anything since anything can be converted to string 18:06:12 VD: 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? 18:06:35 Lachy has joined #webapps 18:07:18 TL: i think action should be to clarify the spec and then we can discuss what we want behavior to be 18:08:30 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 18:08:46 s/VD/VK/ 18:09:38 JS: I think TC-39 will have strong opinions on this. I know mark miller did 18:09:50 MJS: not sure i understand MMs objection 18:11:56 MJS: one issue is that overloads allows overloads to be added in [supplemental] interfaces. Would not match ES5 implementations 18:12:18 SW: we could forbid overloading in supplementals 18:14:30 ...discussions about XHR... 18:16:11 SW: 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 18:16:31 SW: i'd also like to know how you reference one of the specific overloads 18:17:26 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 18:18:04 TL: problem is that we have a spec that's hard to understand. Using union types might make it easier for people to understand it 18:18:55 CM: would like to wrap up 18:19:12 darobin, no union types for you! 18:19:45 SW: we need to figure out replaceable 18:20:00 TL: I'm also concerned about mixin's 18:21:00 TL: TC-39 would like to deprecate callable objects 18:22:08 JS: gecko only has a single object that's callable, the document.all object 18:22:21 SW: would like to remove getters/setters without name 18:23:10 TL: remove it 18:24:07 MJS: from javascripts point of view it doesn't have a behavioural difference 18:24:25 CM: proposed resolution: nuke it 18:24:54 DS: remove it but put a note that you did so, so that people can whine 18:25:23 RESOLUTION: remove unnamed getters/setters 18:26:35 Action: weinig to clarify method overloading section and make it readable 18:26:35 Created ACTION-439 - Clarify method overloading section and make it readable [on Samuel Weinig - due 2009-11-10]. 18:27:41 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 18:27:47 TL: I don't care 18:28:39 恗恍ļ¼šshould be core 18:28:39 SO: i'd prefer a separate syntax 18:28:53 hands off my editing! 18:28:59 s/editing/scribing/ 18:31:01 SW: who volunteers to provide tests? 18:31:36 SO: i do! 18:32:12 s/who volunteers to provide tests/who volunteers to provide DOM L2 based tests/ 18:32:33 s/provide/fish out and expand on heycam's/ 18:33:34 s/恘恍/史ē“€ 18:33:38 JS: I'll do the DOM 2 ones 18:34:10 RRSAgent, make minutes 18:34:10 I have made the request to generate http://www.w3.org/2009/11/02-webapps-minutes.html MikeSmith 18:34:22 s/SO: i do!// 18:34:43 SO: I'll do C++ tests 18:34:48 s/恗恍/史ē“€ 18:35:01 http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0338.html 18:35:14 Topic: Selectors 18:35:15 http://dev.w3.org/2006/webapi/selectors-api/#nodeselector 18:35:18 RRSAgent, make minutes 18:35:18 I have made the request to generate http://www.w3.org/2009/11/02-webapps-minutes.html MikeSmith 18:35:31 LH: i need to finish up test suite 18:35:59 LH: spec is ready for CR, can do tests in parallel 18:36:14 TL: namespace resolvers still out? 18:36:32 LH: yes, may potentially be in selectors L2 18:37:34 http://dev.w3.org/2006/webapi/selectors-api2/ 18:37:39 BREAK 18:39:27 root has joined #webapps 18:51:39 smaug_ has joined #webapps 18:58:06 markusm has joined #webapps 19:05:45 Topic: DOM 3 Events 19:06:07 mjs has joined #webapps 19:09:00 ArtB has joined #webapps 19:10:06 gsnedders has joined #webapps 19:11:31 omw 19:11:51 won't be there (but thanks) 19:12:04 Present+ Ishida, Addison, NorbertL 19:12:22 Present+ Hixie 19:12:38 Scribe: Sicking 19:13:22 ArtB has changed the topic to: WebApps agenda Nov 3: http://www.w3.org/2008/webapps/wiki/TPAC2009APIs#Tuesday.2C_November_3 19:13:38 Present+ Mikeā„¢ 19:13:46 DS: suggestion to make key values, instead of being "\\u1234", to be "\u1234". I.e. be the actual character 19:13:47 darobin has joined #webapps 19:13:57 JonathanJ has joined #webapps 19:14:22 http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#js-escape 19:14:50 AP: this results in a surrugate pair being the value 19:14:58 s/"\\u1234"/"U+1234" 19:15:03 AP: this problem didn't exist with the old "U+1234" syntax 19:16:19 JS: is this a problem? 19:16:36 AP: it means to get the actual character value you might need to decode the surrugate pair 19:16:47 s/surrugate/surrogate/ 19:16:51 (i follow standards) 19:17:27 AP: there are lots of surrogate characters 19:17:36 AP: and more with time 19:18:19 DS: maciej wasn't sure that there are keys that result in a non BMP character 19:18:26 DS: however there appears there are 19:18:55 DS: characters "tree stub" and "untidy" are such characters 19:19:15 my old suggestion of "\u1234" was meant to suggest the values should be a string of the actual character 19:19:44 so for example the identifier when you press lowercase a would be the string "a" 19:19:47 Marcos has joined #webapps 19:20:02 IH: for people that compare with a string, then the fact that it's a surrogate pair then this isn't a problem 19:20:17 DS: complicated in some situations 19:20:19 IH: when? 19:20:38 DS: when people use lots of supplementary characters in the script. Maybe 19:20:59 JS: can someone show code that they are concerned about won't work 19:21:24 VagnerW3CBrasil has joined #webapps 19:23:08 ...confusion about what is actually suggested... 19:25:07 [Do you get "U+1234" or "Ʀ" or "\u1234" and is there any reason to distinguish the second and third cases?] 19:28:13 Scribe: chaals 19:28:48 RI: You take a character outside BMP, and your javascript escape is "\1234\5678" 19:29:09 PA: The string that is the individual character is length 2 19:29:58 RI: why move away from the "U+1234" format? 19:31:27 Zakim has left #webapps 19:31:28 RRSAgent, make minutes 19:31:28 I have made the request to generate http://www.w3.org/2009/11/02-webapps-minutes.html MikeSmith 19:31:39 Zakim has joined #webapps 19:31:46 q+ sicking 19:32:03 tlr has joined #webapps 19:32:27 q+ rob 19:32:40 DS: if i'm trying to limit a form to just one character, i might reject surrogate pair characters 19:33:15 q+ 19:33:18 q+ 19:33:48 q- 19:33:59 q+ r12a 19:34:11 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 19:34:24 JS: my concern is that we're trying to work around behavior in ES 19:34:40 Kai has joined #webapps 19:34:47 ack si 19:34:52 ack rob 19:34:53 AP: i just want people to know what the ramifications are, and that we make it clear in spec 19:36:54 q? 19:37:09 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 19:37:45 RE: for keys like "F1" we can use a different field 19:37:46 ack annevk 19:38:15 AvK: the way javascript deals with i18n should be an orthogonal issue 19:39:08 q+ 19:39:13 AP: we should follow the way that javascript deals with i18n 19:39:19 ack r12 19:39:23 AP: even if that isn't perfect 19:40:07 RI: i want to know how this is expected to be used 19:40:38 RI: if you just want a label for what was pressed then "U+1234" syntax seems better 19:40:55 ack she 19:41:05 RI: so trying to understand what the use cases and expected uses are 19:41:19 DS: comparisons often 19:42:49 JS: If the characters are described as double-escaped bytes, you can still do comparison with them 19:43:09 '\uFFFF' < '\u10FFF' => false 19:44:07 fsasaki has joined #webapps 19:44:55 Present+ Felix 19:45:12 JS: Does any use case run up against that painful gap in practice? 19:45:23 DS: range checks might also be common 19:46:40 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 19:47:51 IH: I think we are fine because I don't think we will meet the boundary case 19:47:55 myakura has joined #webapps 19:47:55 q+ anne 19:48:10 q+ 19:48:10 ack anne 19:48:51 IH: in fact, the "U+1234" syntax compares even worse for range checks 19:49:31 AvK: I don't think we should try to work around ES problems 19:50:23 q+ addison 19:50:35 ack she 19:50:39 ack add 19:52:07 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. 19:52:22 q+ 19:52:33 AP: if you tie yourself to UTF16, then that could be a problem. 19:52:38 ack hi 19:54:00 AI: if i have a ascii page, how would i use this 19:54:10 pcastro has joined #webapps 19:55:27 AvK: the spec would simply say, U+1234, without quotes 19:55:36 AvK: that's what other specs do 19:56:13 DS: i was confused, but now i can see 19:56:51 IH: WebIDL will handle it 19:57:00 DS: will that be clear for authors 19:57:15 IH: should have a separate section that describes things for authors. You probably want that anyway 19:57:23 DS: i would like to express a resolution 19:57:47 s/DS: i would like to express a resolution// 19:58:55 RESOLUTION: the value will be a character. WebIDL will clarify how this is mapped to ES 20:00:24 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/ 20:00:40 action: shepazu to add clarification for authors of JS where the gotchas are 20:00:40 Created ACTION-440 - Add clarification for authors of JS where the gotchas are [on Doug Schepers - due 2009-11-10]. 20:00:42 these are unicode scalar values 20:00:54 tlr has joined #webapps 20:00:56 RATIONALE: WebIDL makes sure that this comes back in the relevant form for whatever language you are using 20:01:14 to aid developers we probably need to make the non-character values (like "F1") be not length-2 20:01:49 e.g. "[F1]" or "*F1" or "F-1" or "Function1" or something 20:01:54 q? 20:02:33 NL: when I do ē§€, how many events are there? 20:02:59 q+ 20:03:00 [it took me about a dozen key presses to make that character] 20:03:03 q- 20:03:24 q+ to suggest we declare conversion methods out of scope 20:03:33 DS: when you have IME, you have there's a bunch of composition events'n'stuff 20:05:08 DS: the whole things is very complicated. Might be best for people to review the spec 20:05:27 AP: when should we review 20:05:37 CM: over lunch 20:05:43 DS: the sooner the better 20:05:58 q+ to mention that i18n group is having IRI discussion from 1pm to 3pm 20:06:04 DS: spec should be pretty stable now. Especially with this latest resolution 20:06:16 ack ann 20:06:16 annevk, you wanted to suggest we declare conversion methods out of scope 20:06:27 AvK: I propose we drop the conversion methods 20:07:00 DS: i would like to keep them 20:08:57 q+ sam 20:09:08 DS: we want people to deal with characters, so I think it's in scope 20:09:15 q- later 20:09:28 tlr_ has joined #webapps 20:09:42 q+ chaals 20:09:42 AvK: ES needs to solve it in a larger scope 20:09:47 ack sa 20:09:55 q- cha 20:10:17 pcastro has left #webapps 20:10:20 SW: I think the right place to put it is on the ES String constructor, other languages have it there 20:11:15 SW: there are docs on the web that shows how to take a multibyte character and turn it into a numerical codepoint 20:11:15 q+ chaals 20:11:18 DS: the code is HUGE 20:11:24 q- later 20:11:24 SW: no it's not 20:11:28 DS: yes it is 20:11:32 SW: no it's not 20:11:37 [it is 15 lines] 20:11:51 http://rishida.net/tools/conversion/ 20:12:28 DS: lets continue discussion later 20:13:47 q- 20:13:53 ack chaals 20:14:08 tlr has joined #webapps 20:14:15 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 20:15:03 CM: who would rather move it to ecmascript 20:15:15 ...straw poll is taken... 20:15:24 [Shepazu objects, no resolution] 20:18:01 DS: Hixie had requested that some events be defined in much greater detail, or be removed from the DOM L3 Events spec 20:18:13 AvK: I can represent hixie 20:18:37 AvK: Problem is that it's very fuzzily defined when certain events are dispatched 20:19:54 TL: it's not expected that DOM Events define exactly when the events are fired 20:20:10 TL: and that the hosting language should define that 20:20:16 q+ 20:20:49 TL: this was also raised with progress events yesterday 20:21:09 TL: resolution was to define what the event looks like, but let hosting specs define when they are fired 20:21:14 q+ 20:22:08 AvK: mouse events for example can be just generic events. Don't need to be in DOM Events spec 20:22:40 q? 20:22:53 ack si 20:22:56 DS: if there's a risk that hixie will raise objections, then i'd rather adress the issue sooner than later 20:23:58 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. 20:24:31 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 20:24:39 oh, thanks chaals 20:24:53 arve has joined #webapps 20:24:56 JS: though i don't know who would define mouse events since they seem cross language 20:25:11 AvK: possibly CSSOM could define mouse events 20:25:31 CSSOM View 20:26:05 CM: sounds like a meta-discussion. Would like to see specific proposals 20:26:07 ack wei 20:27:02 SW: DOM Events seem like the wrong place to define when mouse events are fired since it involves hit testing 20:27:13 SW: some other spec or specs could define hit testing 20:27:29 CM: still sounds very meta to me 20:27:50 arve has joined #webapps 20:28:40 RESOLUTION: convertKeyValue will be removed from DOM L3 Events 20:29:03 closing ISSUE-110 20:29:04 if you can't follow that part of this transcript, I don't blame you 20:29:06 in recess 20:29:07 (after further consideration DS withdraw his objection) 20:30:01 close ISSUE-110 20:30:01 ISSUE-110 Should we remove the code-point conversion from the D3E spec? closed 20:35:47 Marcos has joined #webapps 21:02:00 i'm in i18n but i'd like to attend the database stuff 21:02:11 so i'll be down when i can 21:08:33 Nikunj has joined #webapps 21:10:39 MikeSmith has joined #webapps 21:12:24 ok. we start at 13.30 21:13:20 just call me Hixie :-) 21:13:31 or you can call him the Other Ian 21:13:33 either works :-P 21:14:25 IIan 21:14:28 tlr has joined #webapps 21:15:10 Marcos has joined #webapps 21:15:36 ageenda+ different storage systems 21:15:48 agenda+ different storage systems 21:15:52 markusm has joined #webapps 21:16:02 agenda+ Web DB (sqlite) 21:16:21 agenda+ WebSimpleDB 21:16:28 agenda+ datacache 21:17:37 zakim, allow this agendum 15 minutes 21:17:37 I do not know what agendum has been taken up, chaals 21:18:37 i can answer questions, not sure i have much to say though 21:19:07 i'm happy to have a quick q&a 21:19:27 ok, we'll see if people have questions and schedule some time if so. 21:20:36 Kai has joined #webapps 21:21:35 mjs has joined #webapps 21:27:43 Lachy has joined #webapps 21:28:29 sicking has joined #webapps 21:32:02 annevk has joined #webapps 21:32:08 weinig has joined #webapps 21:32:28 shiki has joined #webapps 21:32:58 shepazu has joined #webapps 21:35:30 zakim, room for 4 for 90 minutes? 21:35:31 ok, chaals; conference Team_(webapps)21:35Z scheduled with code 26631 (CONF1) for 90 minutes until 2305Z 21:36:08 jorlow has joined #webapps 21:36:36 Vladimir has joined #webapps 21:36:54 michaeln has joined #webapps 21:38:05 Team_(webapps)21:35Z has now started 21:38:12 +Widgets 21:38:28 zakim, widgets is really apis-db-stuff 21:38:28 +apis-db-stuff; got it 21:38:41 pcastro has joined #webapps 21:39:47 adrianba has joined #webapps 21:40:04 ScribeNick: timeless 21:40:07 pablo, did you get the code? 21:40:07 Scribe: timeless 21:40:23 yes, thanks, will call in in a minute 21:40:30 zakim, next agendum 21:40:30 agendum 1. "different storage systems" taken up [from chaals] 21:40:38 zakim, agenda? 21:40:38 I see 4 items remaining on the agenda: 21:40:39 1. different storage systems [from chaals] 21:40:40 2. Web DB (sqlite) [from chaals] 21:40:40 3. WebSimpleDB [from chaals] 21:40:41 4. datacache [from chaals] 21:40:43 pererik has joined #webapps 21:40:45 Topic: different storage systems 21:41:42 + +1.206.369.aaaa 21:41:43 agenda+ filesystem 21:41:45 eric_uhrhane has joined #webapps 21:41:58 zakim, aaaa is Chris 21:41:58 +Chris; got it 21:42:21 -Chris 21:42:33 ifette has joined #webapps 21:42:49 +Chris 21:42:59 Zakim, who's here? 21:42:59 On the phone I see apis-db-stuff, Chris 21:43:01 On IRC I see ifette, eric_uhrhane, pererik, adrianba, pcastro, michaeln, Vladimir, jorlow, shepazu, shiki, weinig, annevk, sicking, Lachy, mjs, Kai, markusm, tlr, MikeSmith, 21:43:05 ... Nikunj, arve, Zakim, JonathanJ, root, arun, chaals, timeless, aroben, hober, timely, Hixie, smaug, RRSAgent, karl, Dashiva, krijnh, fearphage, gavin_, gsnedders|work, inimino, 21:43:07 ... trackbot 21:43:49 pcastro, are you on the phone as well? 21:43:53 Zakim, next agendum 21:43:53 agendum 2. "Web DB (sqlite)" taken up [from chaals] 21:44:08 Topic: Multiple storage systems 21:44:15 zakim, allow this agendum 15 minutes 21:44:15 ok, chaals 21:44:45 chaals: We have a lot of these. how many are in conflict. how many are competing 21:44:56 IH: none and all respectively 21:44:58 sicking: Web DB and Web SimpleDB are competing 21:45:18 sicking: whatever we come up with for Web DB / Web Simple DB will replace a lot of localStorage 21:45:21 +[Microsoft] 21:45:38 IanF: Are people trying to throw localStorage out the window or discourage it? 21:45:51 sicking: the way things are going, localStorage is going to be racy 21:46:05 ... even storing the numbers between 1 and 2, you should probably not use it 21:46:39 chaals: at opera, we implemented web db 21:46:50 ... we looked at web simple db. we found web db nice and simple 21:47:29 Web DB = The SQLite One 21:47:37 WebSimpleDB = The Nikunj One 21:47:54 s/web db nice/the nikunj one/ 21:48:02 chaals: we found Nikunj to be more to our liking 21:48:08 arun: yes i'm on the phone as well, trying to follow 21:48:29 chaals: we have implemented Nikunj internally 21:49:15 s/Nikunj/WebDB/ 21:49:25 Travis has joined #webapps 21:49:37 sicking: we don't have a data point 21:49:48 ... we've had a lot of discussions, primarily with MS and Oracle 21:50:02 ... Oracle stands behind Nikunj 21:50:08 ... we've talked to a lot of developers 21:50:15 ... the feedback we got is that we really don't want SQL 21:50:54 IanF: We've implemented WebDB 21:51:04 ... we're about to ship it 21:51:23 MJS: We've implemented WebDB and have been shipping it for some time 21:51:27 ... it's shipping in Safari 21:51:33 IanF: we're also interested in the Nikunj One 21:51:38 ... the Chrome implementation shares some but not quite all of the code 21:51:53 ... beside shipping it, web sites have versions that target the iPhone and use it 21:52:03 ... we can't easily drop it in the near future for that reason 21:52:15 ... In principal, having a storage mechanism that is more sound than localStorage 21:52:28 ... but more simple than WebDB would be good 21:52:45 ... wrt localStorage, the current bits indeed have race conditions 21:52:53 ... but adding APIs could possibly fix it 21:53:14 ... SimpleDB / WebDB is probably impossible because of 21:53:37 jorlow: a large percentage of a lot of the web apps that google is looking at 21:53:44 ... would need a large percentage of what is in SimpleDB 21:53:51 ... in order to make an extended localStorage usable 21:54:10 q+ 21:54:16 ... it would be fine to make localStorage do it, but it would require a lot of SimpleDB 21:54:23 MJS: [lost] 21:54:37 Nikunj: [lost] 21:54:57 Nikunj: (to MJS) do you want to keep the API as is or the functionality as is 21:55:08 ... the localStorage API is synchronous only 21:55:09 s/Nikunj: [lost]/We can make simpleDB do everything localstorage does/ 21:55:23 MJS: you would need to do a superset in order to handle locking 21:55:29 q? 21:55:33 jorlow: Google is not happy with the various proposals 21:55:34 ack adrianba 21:56:03 AB: Microsoft's position is that WebSimpleDB is what we'd like to see 21:56:19 ... we don't think we'll reasonably be able to ship an interoperable version of WebDB 21:56:32 ... trying to arrive at an interoperable version of SQL will be too hard 21:56:48 ... what people want is a ... 21:56:51 Marcos has joined #webapps 21:57:03 ... we think that WebDB (?) features is a starting point 21:57:22 ... we don't plan to add to localStorage 21:57:38 jorlow: so you don't plan to change localStorage 21:57:44 AB: localStorage won't go away 21:57:54 ... but we don't intend to extend it 21:58:17 s/plan to change localStorage/enhance localStorage...for example, implement the storage mutex/ 21:58:25 ... we don't think that people will be able to benefit from making it more complicated (?) 21:58:48 sicking: I haven't thought about the idea of extending localStorage 21:59:01 ... before i form a strong opinion, i'd like to see a proposal, but it seems hard 21:59:16 PC: [?] 21:59:16 chaals, agendum 2 was to have been concluded at this time 21:59:32 michaeln: SimpleDB doesn't overlap with localStorage 21:59:40 ... there are no events in SimpleDB 21:59:53 MJS: so it isn't a superset of (localStorage) functionality 22:00:00 PC: Don't see that it is interesting to try and extend localstorage 22:00:01 sicking: there's always value in having less features 22:00:25 MJS: localStorage is rather nascent, but it seems rather unfortunate that we're discussing orphaning it 22:00:31 yes, i agree, extending localStorage to cover the functionality of SimpleDB is the same as introducing a new simpledb API, given the delta... 22:00:35 sicking: I agree, but i haven't seen any workable proposals 22:00:51 PC: localStorage is useful for simple tasks 22:01:01 ... for registry keys (preferences) in windows apis 22:01:11 sicking: the problem with it is the raciness 22:01:22 ... no one working on a multi process browser has safely handled this 22:01:27 chaals: we're out of time. 22:01:38 ... there's a lot of push for Nikunj 22:01:43 ... where does that leave WebDB? 22:01:48 ... Apple can't stop shipping it 22:01:52 ... Google will be shipping it 22:02:00 ... Opera has not yet shipped it 22:02:09 ... but it's likely we will as people have built on it 22:02:15 sicking: I don't think mozilla plans to ship it 22:02:53 DS: you could do the same things with Nikunj as with localStorage 22:02:57 ... except storage events 22:03:13 cwilson: the difference is... 22:03:21 ... you get the ability to have a lot more data in it 22:03:27 ... in a much more organized way 22:03:38 (there's also sessionStorage, fwiw) 22:03:44 s/cwilson/PC/ 22:03:48 ... you don't need to learn another language to get data in/out 22:03:57 chaals: i don't see a conclusion 22:04:03 VagnerW3CBrasil has joined #webapps 22:04:10 sicking: I don't have any plans to review WebDB 22:04:15 darobin has joined #webapps 22:04:24 IH: I'd rather not spec WebDB if people don't want to ship it 22:04:26 q+ 22:04:40 DS: I was talking with w3c people about the confusion 22:04:53 ... there are several web storage proposals, and we think that it clutters developer mind space 22:04:57 q? 22:05:11 IanF: I don't think people are in disagreement that it's sad 22:05:16 ... it's a bit too late 22:05:17 Topic: WebDB - sql lite 22:05:22 ... let's look at something else, but let's move on 22:05:39 cwilson: I don't know if anyone has suggested on the group of killing off WebDB on the list 22:05:45 DS: except the editor 22:05:49 [ laughs of agreement ] 22:05:57 MJS: it sounds like there will be multiple shipping implementations 22:06:10 cwilson: it seems with multiple interoperable implementations 22:06:15 ... that you can't really call it stillborn 22:06:22 s/q+ 22:06:25 q+ 22:06:27 ... when we started looking at WebDB 22:06:38 ... the reason we liked Nikunj was that it doesn't impose 22:06:45 ... but it has the power 22:07:08 ... the part that concerned us with WebDB is that it presupposes SQLite 22:07:13 ... we're not really sure 22:07:22 IanF: i don't think anyone disagrees 22:07:40 q- 22:07:42 ... I haven't heard anyone say they don't like Nikunj , i've heard a lot of interest in it 22:07:52 IH: Proposal 22:08:03 ... all the browsers shipping WebDB are WebKit based 22:08:19 ... proposal: we move WebDB to WebKit.org, and we kill it as a deliverable from this group 22:08:27 chaals: I think we're likely to ship it 22:08:31 q+ 22:08:31 Marcos has joined #webapps 22:08:37 ack cha 22:08:39 IH: I don't want to work on a spec without 5/5 impls 22:08:53 DS: Is it possible to take what is speced in WebDB, freeze it, 22:09:03 ... take the interface layer, and stick it onto Nikunj ? 22:09:08 [all] : No. 22:09:18 ack arun 22:09:20 q+ 22:09:30 arun: suppose the freezing part was taken seriously 22:09:38 ... is that sufficient, or is there more spec needed to be written? 22:09:43 IH: well, there's the SQL part 22:09:53 q+ sam 22:09:54 ... we could say that the SQL part is SQLite 3's dialect 22:09:59 q+ sam 22:10:03 ack she 22:10:06 ack sam 22:10:23 q+ 22:10:32 sam: spoke 22:10:55 Sam: Apple and Google have expressed an interest in added full text search to the api we've used 22:11:05 jorlow: that's extremely important to Google too 22:11:13 q- 22:11:19 [ audience squirmed relating to some Xsomething api] 22:11:39 ack me 22:11:48 IH: most of the people are asking me to spec Nikunj (?) 22:12:15 chaals: moving along 22:12:28 ... proposal: WebDB remains as a deliverable 22:12:46 q+ 22:12:51 ... we ask IH to do the minimal level to satisfy the implementors 22:12:56 RESOLVED: [above] 22:13:10 zakim, next agendum 22:13:10 I see a speaker queue remaining and respectfully decline to close this agendum, chaals 22:13:24 q- 22:13:27 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 22:13:31 q- pablo 22:13:38 JonathanJ has joined #webapps 22:13:44 ack pcastro 22:13:47 zakim, next agendum 22:13:47 agendum 3. "WebSimpleDB" taken up [from chaals] 22:14:10 chaals: do we really want to talk about filesystem? 22:14:14 arun: no 22:14:23 ianf: no, except to remember it exists 22:14:23 zakim drop agendum 5 22:14:29 zakim, drop agendum 5 22:14:29 agendum 5, filesystem, dropped 22:14:52 s/ianf/ifette 22:14:53 Topic: Web Simple DB 22:15:04 s/DB/DB (nikunj) 22:15:08 s/DB/(Nikunj) DB/ 22:15:31 chaals: ack Nikunj 22:15:42 [ Nikunj asks for projection ] 22:15:57 Zakim, allow this agendum 30 minutes 22:15:57 ok, ifette 22:16:21 [ chaals asks for intros from lurkers ] 22:16:34 Donald from ETH Zurich 22:16:55 Donald: We've implemented XQuery that runs in IE and FF, and hopefully soon in Chrome/Opera/Safari 22:16:59 gsnedders has joined #webapps 22:17:23 Ghislain a student of Donald 22:17:35 Dana from Oracle 22:17:50 HTML working group chair 22:18:27 Satoshi 22:18:41 [?] from Toshiba 22:19:33 s/[?]/Gondo/ 22:19:39 Nikunj: there's a new draft, taking input from others and feedback from the mailing list 22:19:43 Magnus, Ericsson 22:19:58 Nikunj: there are some use cases we don't cover 22:20:06 ... JS might want to do boolean expression evaluation 22:20:23 ... the language for the expression isn't important 22:20:35 ... but the necessary bits to efficiently implement this 22:20:56 ... being able to store keys, iterate over keys in the index, operate over multiple keys at the same time 22:21:17 Nikunj: I plan to add appendices to help with this (?) 22:21:22 ... before the next working draft 22:21:34 ... there are some open questions that i haven't addressed in this spec 22:21:47 ... i'd like to lay out things to get feedback for alternate suggestions 22:22:11 Nikunj: first, key types 22:22:20 ... string/number 22:22:38 ... the are fancier things that could be done, supporting structured clone as a key value 22:22:47 [functions that evaluate to a value can be a key, too] 22:22:48 ... there are various ways to make it fancier 22:23:02 q? 22:23:16 q+ ifette 22:23:25 Nikunj: there are multiple ways to address this 22:23:32 RRSAgent, make minutes 22:23:32 I have made the request to generate http://www.w3.org/2009/11/02-webapps-minutes.html MikeSmith 22:24:08 Nikunj: there are three ways to do indexing 22:24:18 ... 1. no indexing, the application manages the index manually 22:24:29 ... 2. the index only knows about the store, but the useragent doesn't maintain that index 22:24:40 ... it is only used by the application to look up things through the index 22:24:51 ... 3. in addition to 2, the useragent actually maintains the index 22:25:02 Nikunj: option 1 is supported 22:25:13 ... option 3 is supported with constraints on the key path 22:25:16 q+ to ask question aboujt indicies 22:25:18 ... option 2 is not supported 22:25:32 ... option 3 is a simpler api but more complex implementation 22:25:50 ... there's a contention between reducing the footprint of the api v. the footprint of the implementation 22:26:02 ... there are tradeoffs across different engines 22:26:28 ... i've tried to capture an implementation neutral api 22:26:42 ... i'm requesting feedback to be categorized, api v. footprint 22:26:52 ... i've received feedback on concurrency 22:27:10 ... there are two models for concurrency 22:27:19 ... optimistic and pessimistic 22:27:23 ... i've tried to avoid mandating an implementation 22:27:30 ... implementations will choose based on their needs 22:27:44 ... optimistic is better for high performance 22:27:55 ... pessimistic is simpler 22:28:08 ... in the spec, i've tried to identify conditions that can offer deadlock free behavior 22:28:23 ... i believe the main concern, is that the average user will not be very good at recovering from 22:28:33 ... deadlocks or optimistic concurrency failure 22:28:46 ... the approach i've taken is to specify a behavior that is deadlock free 22:29:06 ... and specify two levels of granularity that 22:29:13 ... at the database, or an object store 22:29:26 ArtB: could you document this in a blog? 22:29:33 Nikunj: Object Store = Table 22:29:42 DS: better in a requirements document than a blog 22:29:44 --> http://dev.w3.org/2006/webapi/WebSimpleDB/ editor's draft 22:29:50 q? 22:30:01 Nikunj: let me start writing it in an appendix, and then we can move it to another document later 22:30:03 q+ sicking 22:30:05 ack ifette 22:30:05 ifette, you wanted to ask question aboujt indicies 22:30:12 q= ifette,sicking 22:30:19 queue=ifette,sicking 22:30:19 \ 22:30:23 Nikunj: two levels of deadlock free concurrency 22:30:26 ... comparing with WebDB 22:30:33 ... where we only do database level concurrency 22:30:49 scribe: Chaals 22:30:59 ... and object storage level 22:31:06 s/storage/store 22:31:15 q+ to full text indexes 22:31:17 ... main pont is that people have asked for even more concurrency where possible. 22:31:31 s/pont/point/ 22:31:41 ... optimistic concurrency control and management, but there is a risk of failiures in concurrency management that exposes programmer to requiring recovery 22:32:03 ... proposal is to allow that to programmers through exiting API knowing that can lead to exceptions that need recover 22:32:15 s/exiting/existing/ 22:32:28 ... 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) 22:32:36 q? 22:32:48 ... Propose to leave it in, as an appendix outside the basic part so people don't stumble. 22:32:56 ack ifette 22:33:10 IF: Wanted to jump back to indices. What do the 3 options mean for an app developer with a lot of data 22:33:36 ... assume 20GB database of integers. Which option gives me a Btree in the user agent, instead of in JS 22:33:52 NM: The btree is in the user agent. you only pull out the data you are looking to consume. 22:34:09 ... to find out which pieces of data match the two conditions, you have to do the join yourself. 22:34:29 ... People feel that a user agent implementation of that might be too rigid, and doing it in the app will be almost as performant. 22:34:49 ... 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 22:34:57 IF: Scares me but I need to go back and get more detail. 22:35:10 ... What base index types do you expect all UAs to support? 22:35:38 NM: Use case for me is a boolean index exression evaluation. Another use case is keyword and context - fulltext. 22:36:03 ... you could create keword/context index, but will not perform as well as done natively. 22:36:29 ... 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. 22:36:49 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. 22:36:56 ... For v1 22:37:34 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. 22:37:46 ... fulltext is probably a bigger spec than websimpleDB. 22:38:01 [clarification of fulltext vs keyword/context] 22:38:24 q? 22:38:25 IF: If we had a quick index that might suffice... let's come back 22:38:28 ack sic 22:38:48 JS: The issue I found most controversial internally has been the concurrency issue 22:38:50 tlr_ has joined #webapps 22:38:56 [ed. Jonas said the unfancy word :P] 22:39:29 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. 22:40:15 ... 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. 22:41:04 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. 22:41:42 ... 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 22:42:13 IF: 3 options are all guaranteed to be dealock-free. Is that a hard requirement or could we offer low-level locking ??? 22:42:46 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. 22:43:22 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. 22:43:34 i/JS: my concern is that/scribenick: sicking 22:43:40 q? 22:43:40 RRSAgent, make minutes 22:43:40 I have made the request to generate http://www.w3.org/2009/11/02-webapps-minutes.html MikeSmith 22:43:41 NM: Yes you can add levels of granularity as well as deadlock free mechanisms 22:43:45 ack j 22:43:45 jorlow, you wanted to full text indexes 22:43:58 JO: Question about joins - sounds like you took them out to keep the implementation simpler 22:44:07 NM: And keep the API smaller 22:44:20 JO: Main concern was implementing joins in Javascript. 22:45:19 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. 22:45:45 JO: So if you have two large parts of the DB with small verlap, doing that in JS is going to be inefficient. 22:45:56 IF: Fulltext is an example - like that. 22:45:58 ifette, agendum 3 was to have been concluded at this time 22:46:15 Zakim, thank you for the oh so curteous reminder 22:46:15 I don't understand you, ifette 22:46:22 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 22:46:24 Zakim, who's your daddy? 22:46:24 Ralph is taking good care of me but you all are my family, ifette 22:46:59 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. 22:47:12 JO: If you have 10k items, that's heavy 22:47:20 NM: Marshalling cost is high 22:47:56 IF: When using the same index repeatedly, how complex? 22:48:07 q+ 22:48:08 NM: if needed it would be an extrsa feature in the spec 22:48:46 SW: concrete question - a person coming from SQL API - how different is the code they have to write, what is the conversion 22:48:54 NM: A user programming against the API? 22:48:57 SW: Sure 22:49:26 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. 22:49:30 q? 22:49:33 q+ 22:49:39 ... if you are using a mapping laer here there will be no real difference 22:49:53 SW: Is there precedence for adding a new API mostly for middleware? 22:50:33 Timeless: We added a lot of stuff to libraries against APIs 22:50:52 AR: It is wise to look at this API to make simple things simple, but look at allowing libraries to straddle it. 22:51:03 q+ 22:51:05 SW: Not sure that this is simpler for a simple query, which is the basic use case for a DB 22:51:08 ack we 22:51:35 AR: Not sure how much more simpler it will be to use SQL 22:51:56 jonas: most people use XHR via libraries 22:52:02 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 22:52:12 Lachy has joined #webapps 22:52:14 SW: remains to be seen for WebGL 22:52:25 AR: Think XHR is a good answer for Sam's question. 22:52:37 SW: Would like to see simple examples converted and how easy they are 22:52:45 NM: Those are already in the front of the spec. 22:53:09 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. 22:53:10 q? 22:53:25 ack arun 22:53:32 ack if 22:54:12 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 22:54:16 [bike shedding] 22:54:27 q+ 22:54:27 ... I can make my app work with this. 22:54:39 s/this/this probably/ 22:54:50 AR: Would like to see libraries that straddle this 22:55:06 Topic: DataCache 22:55:16 s/[bike shedding]// 22:55:31 SW: It would be nice to see a performance analysis 22:55:57 NM: Yes, we need implementation experience to do that. 22:56:25 Magnus has joined #webapps 22:56:39 NM: Bulk of feedback on data caching / http interception seems like appcache but it uses different terminology. 22:56:51 ... people didn't know what they would need to make it happen. 22:57:33 q+ to ask about why this isn't layered on AppCache 22:57:33 ... 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 22:57:38 ack arun 22:57:45 ... appcache doesn't take full headers into account, data cache does 22:58:20 ... 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. 22:58:51 ... 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. 22:59:16 MM: Browser has several forms of auth. reason to check cookies seem to apply to http auth as well. 22:59:33 NM: Yes, that is very valid. In this ersion we are only dfoing cookie, but no reason why it has to be that way. 23:00:07 ... 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. 23:00:29 see example 4.1.1 in datacache draft 23:00:49 chaals: I can do it on list 23:01:55 ... 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 23:01:55 the app. 23:02:27 q+ 23:02:43 ... 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. 23:03:13 q- 23:03:18 ack mjs 23:04:15 MJS: You mentioned ffedback 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. 23:04:31 s/ffedback/feedback 23:06:08 -Chris 23:07:08 pcastro has left #webapps 23:07:39 -[Microsoft] 23:12:39 disconnecting the lone participant, apis-db-stuff, in Team_(webapps)21:35Z 23:12:42 Team_(webapps)21:35Z has ended 23:12:45 Attendees were apis-db-stuff, +1.206.369.aaaa, Chris, [Microsoft] 23:15:37 tlr has joined #webapps 23:16:10 Topic: second CORS 23:17:28 pererik has joined #webapps 23:20:50 annevk has joined #webapps 23:21:59 scribenick: arun 23:22:40 q+ mjs 23:22:49 mjs: [May present a short slide show] 23:24:12 ack mj 23:24:20 hmm, no adam :/ 23:24:22 rrsagent, draft minutes 23:24:22 I have made the request to generate http://www.w3.org/2009/11/02-webapps-minutes.html chaals 23:24:42 +JeffHodges 23:24:43 Jeff Hodges, Paypal 23:25:19 mjs: Gives a presentation on CORS that he commits to putting online soon. 23:27:24 MikeSmith has joined #webapps 23:27:46 Present+ Marcos 23:30:13 shiki has joined #webapps 23:30:38 tlr has joined #webapps 23:30:39 MM: [Points out that "secret token" addresses issues in Origin] 23:34:39 Present+ Benoit 23:35:52 MJS: In access grant (CORS case) you need to add origin check or token (as normal) to protect against CSRF. 23:38:06 mjs: [In the common case, where you're logged in, and permission is granted, diagram illustrates CORS] 23:38:40 hodges has joined #webapps 23:38:53 TC: There's an implicit trust relationship between the Events site and the Calendar site. 23:39:50 TC: 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) 23:41:02 TLR: Turn Server A into an AtomPub server. You want to create a resource, you get the identifier for the resource returned. A page on B uses AtomPub to do something on Server A 23:41:19 s/A page on B/resource on Site B 23:42:33 TLR: 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] 23:42:54 MJS: If Server A only responded with the path part of the URI, there would be no such vulnerability. 23:43:06 TC: But this may also eliminate valid use cases! 23:43:46 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.... 23:44:25 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. 23:44:40 ...by introducing a new protocol that has a vulnerability 23:44:53 MJS: [slide show continues] 23:45:33 MJS: Server M can't forge Origin in browser, combination of cookie + Origin identifies request as valid 23:45:57 MJS: Fancier scenarios can have confused deputy. Site A asking Site B to do something on Site C 23:46:31 MJS: Can also have confused deputy problems without CORS. For example poorly implemented secret tokens. 23:47:02 MJS: [Diagrams this on paper] 23:47:37 MJS: [ Draws sites A, B, C] 23:48:17 MJS: illustrates a scenario where B,and C have an understanding with shared tokens. 23:48:58 MJS: 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. 23:49:26 TC: THe thing that makes CSRF prevalent is that the two initial messages between B and C happen implicitly and automatically. 23:49:46 MJS: CSRF is different. I am simplifying here by considering only servers. 23:50:13 MJS: With CORS, in my simple scenario, doing the dumbest possible thing will be safe. 23:50:30 JS: The simplest way to do authorization on the web today is to use cookies; ergo CSRF problems common 23:51:02 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. 23:51:19 MM: But you will also have a lack of composability amongst servers! 23:51:55 MM: 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. 23:52:06 MJS: That has to count as on behalf of. 23:52:33 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. 23:52:50 MJS: It means that if it does, it is distinguishable from any data from that particular server. 23:53:02 IH: Or you make sure sanitization takes place (a la SQL injection) 23:53:19 TLR: If you want to sanitize, then you must know what the consumer might possibly trigger 23:53:26 MJS: [slideshow continues] 23:54:13 MJS: [gives the example of GMail / Linked In where LinkedIn asks for GMail passwords] 23:54:26 MM: They would prefer to do something else. 23:54:40 MJS: What are non - CORS solutions that could work? 23:54:59 MJS: OAuth could work, generally requires server to server communication. Bilateral agreement (shared secret) 23:55:13 MJS: [Diagrams an OAuth scenario] 23:55:40 MJS: [It is a complex diagram] 23:55:46 JH: [Has a better diagram] 23:55:58 MJS: This is not only in your user agent; it must be programmed in server software. 23:56:06 MJS: You cannot send your shared secret to the client. 23:56:12 MM: This is per request? 23:56:26 MJS: It doesn't have to be per request. The protocol allows token to be valid for e.g. 1 hour. 23:57:41 MJS: [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. 23:57:49 Marcos has joined #webapps 23:58:10 MJS: [Continues discussion of OAuth] Redirects are part of the model. 23:58:15 http://identitymeme.org/archives/2008/10/22/oauth-protocol-flow-diagrams/ 23:58:49 MJS: [ Discussion of OAuth model] Flaws: server to server communication is mandatory. And it's hard to implement correctly. 23:59:13 q? 23:59:22 MJS: Discusses why CORS is an improvement of what is done today. 23:59:55 RE: Also worth discussing is JSONP, which is horrendously evil. 23:59:58 q? 00:00:23 JS: Asks Microsoft -- have you disabled Cookies for cross-site script requests? 00:00:31 AB: [Responds yes] 00:00:49 q+ 00:00:50 MJS: That fixes vulnerability on the site serving the script.... 00:01:12 MJS: I hope to have brought folks up to speed [slide show]. 00:01:16 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 00:01:54 CMN: This is the model used by "Verfied by Visa" right? 00:02:28 CMN: 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. 00:02:38 MJS: I would not claim it is impossible to implement. 00:02:45 MJS: But it might be hard for the casual site developer. 00:02:53 q+ tlr 00:02:56 ack chaals 00:02:59 q+ 00:03:05 q+ markM 00:03:13 q- 00:03:50 ack tlr 00:03:50 AR: [Points out that we did this to improve the world] 00:04:12 TLR: Two frames, + postMessage. Wouldn't that address this problem? 00:04:51 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 mechanism. 00:05:03 s/same mechanism/ same Confused Deputy Vulnerability. 00:05:16 q+ tyler 00:05:17 MJS: Additionally, it needs client side scripts making requests to the API. 00:05:35 TLR: The distinction is that client side code checking origin occurs on the client, as opposed to the server. 00:05:53 MJS: Our worry is not about people making the origin check, but in drawing the wrong conclusion about the origin check. 00:07:00 s/about the origin check/about the implications of the Origin check 00:07:16 IH: You can have a dedicated API with a server-provided API or a JS API 00:07:43 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 00:07:43 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]. 00:07:45 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. 00:08:01 darobin has joined #webapps 00:08:12 MJS: I'd like to analyze this like we've analyzed CORS 00:08:35 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? 00:09:25 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. 00:10:22 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 00:10:31 CMN: .... a worked example. 00:11:05 MJS: I shall send it to the list. 00:11:25 ACTION: Mark to make a worked example of how e.g. GuestXHR would meet the requirements with improved security 00:11:26 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]. 00:11:29 MJS: In a standards compliant format, so that nobody has to live with my company's proprietary format (Keynote) 00:12:00 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. 00:12:24 Kai has joined #webapps 00:12:43 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 it. 00:12:53 q? 00:12:56 s/we may not break it/we may not break compatibility 00:12:58 ack mar 00:13:33 TC: A lot has been made of the existing deployment of CORS. From my study of the specs, there are significant differences between implementations... 00:13:36 q+ 00:14:00 CMN: These are [decisions made] by implementors based on the perceived cost to them. 00:14:00 RRSAgent, make minutes 00:14:00 I have made the request to generate http://www.w3.org/2009/11/02-webapps-minutes.html MikeSmith 00:14:05 q+ 00:14:14 CMN: I don't think security is an on and off thing. 00:15:37 TC: And therefore I am wondering if there is significant content in reality. 00:16:16 AR: There is shipping and compatibility, in apps tehre is erally only geonames, nota great deal of other adoption 00:16:24 https://developer.mozilla.org/En/HTTP_access_control 00:16:27 s/tehre/there/ 00:16:34 s/erally/really/ 00:16:39 'http://arunranga.com/examples/access-control/ 00:16:41 http://arunranga.com/examples/access-control/ 00:16:48 s/nota/not a/ 00:17:03 The URL above shows content working in safari and firefox 00:17:56 Marcos has joined #webapps 00:19:27 [General discussion on TC39/WebIDL] 00:25:18 JonathanJ has joined #webapps 00:30:50 tlr has joined #webapps 00:38:01 Topic: Multi-touch events 00:38:03 scribe: annevk 00:38:13 weinig has joined #webapps 00:38:53 AR: Safari is shipping multi-touch (mt), Firefox will be soon 00:39:11 AR: there are patent risks, but I think we should wait for the exclusion period and see what happens 00:40:01 AR: I think the charter allows for mt 00:40:30 http://www.w3.org/2005/06/tracker/webapi/issues/33 00:40:36 q+ 00:40:40 DS: people disagree on whether it is in the charter 00:40:51 q- tyle 00:40:55 q- arun 00:40:58 DS: it is not listed as deliverable, but is in scope 00:41:39 DS: if someone in the WebApps WG disagrees it is in the charter we have to re-charter in order to do it 00:42:08 RI: we might want to talk to the Device APIs WG 00:42:16 s/RI:/RE:/ 00:42:40 AR: also include orientation event in mt 00:42:53 DS: I believe they are orthogonal so they can be separate 00:42:59 AR: I believe the same group can do it 00:44:21 CMN: we had an issue in the last WG that we inherited about multiple devices interacting with a single device 00:44:32 CMN: sort of similar to mt 00:44:33 Travis has joined #webapps 00:44:42 JS: I think it is different, not just in semantics 00:45:25 CMN: write a spec for mt events 00:45:42 CMN: the spec says it expects to be included in DOM4 Events 00:46:05 AR: I favor separate specs 00:46:39 [bikeshed] 00:47:00 AR: I am willing to co-edit 00:47:05 Marcos has joined #webapps 00:47:37 DS: I like to co-edit 00:47:51 AR: I like to check with OP 00:48:04 ArtB has joined #webapps 00:48:19 RRSAgent, pointer? 00:48:19 See http://www.w3.org/2009/11/02-webapps-irc#T00-48-19 00:49:10 [bikeshed on charter] 00:49:59 CMN: are there objections to adding new events? 00:50:17 RESOLUTION: specifications for new events are in our charter 00:50:46 CMN: we have proposals for mt, orientation, gestures, and pen-tablets 00:51:06 I believe the Geolocation WG is also looking at spec related to Orientation 00:51:07 CMN: we have volunteers; DS and AR 00:51:42 [group overlap bikeshed] 00:52:40 RESOLUTION: DS and AR edit multi-touch, orientation, gestures, and pen-tablets event specifications 00:53:13 [pen-tablet bikeshed] 00:54:12 SO: joystick etc. events? 00:54:16 CMN: if you have proposals 00:54:32 Topic: joint meeting with widget fanboys 00:55:06 http://www.w3.org/2008/webapps/wiki/PubStatus#Widgets_Specifications 00:55:18 http://www.w3.org/2008/webapps/wiki/PubStatus#API_Specifications 00:55:19 AB: editors please fix if there are mistakes 00:55:24 s/event specifications/events specification/ 00:56:34 MC: I wonder how XMLHttpRequest and CORS are going to be tested 00:56:50 SW: You can use one domain with two different ports 00:57:15 DS: we can ask the systems team 00:57:48 send mail to team-webapps@w3.org 00:58:45 DS: can we start a wiki page with a list of required features for tests? 00:59:18 pererik has joined #webapps 00:59:45 AB: we have two dependencies; Web IDL and Web Storage 01:00:07 SW: Web IDL will use ECMAScript 5 concepts which is an invasive change 01:00:39 SW: we want to add tests based on DOM2 IDL converted to Web IDL so we can test the various concepts in Web IDL 01:01:14 SW: we can use that to allow specification editors to move forward with more certainty 01:01:23 JS: I volunteered for some amount of that testing 01:02:12 CMN: you can move ahead in the Rec-track process with a dependency but you have to argue your case 01:02:28 s/dependency/dependency on Web IDL/ 01:02:45 AB: when is there a new draft? 01:02:58 SW: I'm new to editing so I don't really know at this point 01:03:22 MJS: the question is how much editing needs to be done before we want to publish again 01:04:02 MJS: maybe the goal should be to do the ECMAScript 5 conversion and publish after that 01:04:35 IH: Web Storage will go to Last Call this month 01:04:58 Nikunj has joined #webapps 01:05:21 CMN: we want to move to a model where Last Call means the Working Group considers the work to be good 01:06:13 IH: I believe there are no outstanding issues 01:06:29 IH: The W3C side will not be blocked by the WHATWG 01:06:38 IH: I don't perceive major changes to Web Storage ever 01:07:27 ACTION: barstow send out a pre-LC request for comments for Hixie's specs 01:07:27 Created ACTION-449 - Send out a pre-LC request for comments for Hixie's specs [on Arthur Barstow - due 2009-11-11]. 01:07:35 CMN: we found someone to edit ??? and agreed to move XMLHttpRequest to Last Call 01:08:02 CMN: Web Database was only going to be done by 3 out of 5 01:08:16 CMN: more interest in WebSimpleDB 01:10:20 CMN: alternate proposal for CORS which needs further discussion; DOM Events ready 01:11:01 CMN: we did not get into Selectors API 2 01:11:16 AB: news on XBL2? 01:11:48 JS: I'm on temporary project for a while, but I worked on a quarter for it and will get back to it 01:12:23 ACTION: barstow start a CfC to publish FPWD of File API 01:12:23 Created ACTION-450 - Start a CfC to publish FPWD of File API [on Arthur Barstow - due 2009-11-11]. 01:12:48 [thanks bikeshed] 01:13:03 adjourned 01:16:38 markusm has joined #webapps 01:18:21 shiki has joined #webapps 01:29:48 pererik has joined #webapps 01:31:44 shiki has joined #webapps 01:34:54 timeless_mbp has joined #webapps 01:34:59 Marcos has joined #webapps 01:48:51 tlr_ has joined #webapps 01:50:33 annevk has joined #webapps 01:50:50 Marcos has joined #webapps 01:56:12 tlr_ has joined #webapps 01:56:54 Marcos has joined #webapps 02:00:04 tlr_ has joined #webapps 02:02:39 weinig has joined #webapps 02:04:56 tlr_ has joined #webapps 02:05:25 RRSAgent, make minutes 02:05:25 I have made the request to generate http://www.w3.org/2009/11/02-webapps-minutes.html MikeSmith 02:06:25 MikeSmith, you wanna join us to the mall? 02:06:37 MikeSmith, Lachlan and Marcos are also coming, not sure who else 02:08:25 Marcos has joined #webapps 02:08:31 annevk: I'm got to be at the AC meeting, but can catch up with you guys later 02:08:45 what's at the mall? 02:08:53 tlr_ has joined #webapps 02:20:00 tlr_ has joined #webapps 02:37:58 Nikunj has joined #webapps 03:43:02 we're not at the mall 03:45:11 hmm 03:45:11 you're gone 03:49:54 sicking has joined #webapps 04:43:56 jorlow has joined #webapps 05:33:51 timeless_mbp has joined #webapps 06:10:58 Marcos has joined #webapps 06:13:30 Lachy has joined #webapps 06:44:02 weinig has joined #webapps 08:56:55 gsnedders has joined #webapps 09:43:09 arve has joined #webapps 10:01:08 shepazu has joined #webapps 11:05:46 timely has joined #webapps 11:13:31 mjs has joined #webapps 11:20:12 karl has joined #webapps 13:19:43 arun has joined #webapps 13:23:23 ArtB has joined #webapps 13:23:36 RRSAgent, pointer? 13:23:36 See http://www.w3.org/2009/11/02-webapps-irc#T13-23-36 14:27:06 arve has joined #webapps 14:49:11 aroben has joined #webapps 14:55:08 annevk has joined #webapps 15:28:10 myakura has joined #webapps 15:34:13 Nikunj has joined #webapps 15:38:20 timely has joined #webapps 16:16:42 arun has joined #webapps 16:31:58 Marcos has joined #webapps 16:44:53 JonathanJ has joined #webapps 16:44:56 Kai has joined #webapps 16:46:12 MikeSmith has joined #webapps 16:46:41 shepazu has joined #webapps 16:47:05 Marcos has joined #webapps 16:47:39 weinig has joined #webapps 16:48:46 chaals has joined #webapps 16:49:10 chaals has left #webapps 16:51:54 ArtB has joined #webapps 16:52:16 shiki has joined #webapps 16:52:41 darobin has joined #webapps 16:53:09 tlr has joined #webapps 16:58:38 ArtB has changed the topic to: WebApps WG; this channel is logged: http://krijnhoetmer.nl/irc-logs/ 17:00:21 annevk has joined #webapps 17:04:36 Nikunj has joined #webapps 17:08:53 Nikunj has joined #webapps 17:13:07 Lachy has joined #webapps 17:13:58 myakura has joined #webapps 17:14:56 Nikunj has joined #webapps 17:20:28 timeless_mbp has joined #webapps 17:28:44 Nikunj has joined #webapps 17:53:51 Nikunj has joined #webapps 18:04:38 ifette has joined #webapps 18:21:57 JonathanJ has left #webapps 18:22:13 krijnh has joined #webapps 18:22:14 Nikunj has joined #webapps 18:31:49 Marcos has joined #webapps 18:34:01 shiki has joined #webapps 18:35:59 annevk has joined #webapps 18:36:52 darobin has joined #webapps 18:37:21 Lachy has joined #webapps 18:38:38 weinig has joined #webapps 18:39:09 Kai has joined #webapps 18:54:13 JonathanJ has joined #webapps 18:54:45 ArtB has joined #webapps 19:04:04 weinig_ has joined #webapps 19:11:27 gsnedders has joined #webapps 19:11:32 Nikunj has joined #webapps 19:49:23 Lachy has joined #webapps 20:23:38 krijnh has joined #webapps 20:28:59 Lachy has joined #webapps 20:34:35 Marcos has joined #webapps 20:54:54 Nikunj has joined #webapps 20:56:31 Nikunj has left #webapps 20:59:40 Lachy has joined #webapps 21:00:01 Marcos has joined #webapps 21:06:23 Lachy has joined #webapps 21:14:43 Kai has joined #webapps 21:22:59 darobin has joined #webapps 21:24:46 Nikunj has joined #webapps 21:28:53 Lachy has joined #webapps 21:29:07 Nikunj has left #webapps 21:29:08 gsnedders has joined #webapps 21:29:17 Lachy has joined #webapps 21:29:18 shiki has joined #webapps 21:31:12 myakura has joined #webapps 21:32:28 annevk has joined #webapps 21:35:45 tlr has joined #webapps 21:37:57 JonathanJ has joined #webapps 21:38:33 arun has joined #webapps 21:41:36 ArtB has joined #webapps 21:53:34 chaals has joined #webapps 21:53:34 Lachy has joined #webapps 22:04:24 ArtB has joined #webapps 22:05:25 Lachy has joined #webapps 22:29:35 Lachy has joined #webapps 22:30:46 phenny has joined #webapps 22:34:23 Marcos has joined #webapps 22:44:19 shiki has joined #webapps 23:04:16 weinig has joined #webapps 23:25:37 mjs has joined #webapps 23:27:19 JonathanJ has joined #webapps 23:30:44 gsnedders has joined #webapps 23:31:38 sicking has joined #webapps 23:40:19 weinig has joined #webapps 23:44:04 Marcos has joined #webapps 23:51:27 mjs has joined #webapps 00:03:27 Lachy has joined #webapps 00:05:09 darobin has joined #webapps 00:05:23 Kai has joined #webapps 00:07:27 annevk has joined #webapps 00:08:25 ArtB has joined #webapps 00:10:03 tlr has joined #webapps 00:11:04 arun has joined #webapps 00:18:52 phenny has joined #webapps 00:22:19 Marcos has joined #webapps 00:28:34 phenny has joined #webapps 00:30:23 phenny has joined #webapps 00:31:26 phenny has joined #webapps 00:51:06 phenny has joined #webapps 00:51:48 phenny has joined #webapps 01:02:18 shiki has joined #webapps 01:11:08 Nikunj has joined #webapps 01:13:23 Nikunj has left #webapps 01:14:20 phenny has joined #webapps 01:15:39 mjs has joined #webapps 01:34:35 Marcos has joined #webapps 01:40:20 weinig has joined #webapps 01:41:19 action-442: http://sites.google.com/site/guestxhr/maciej-challenge 01:41:19 ACTION-442 Make a worked example of how e.g. GuestXHR would meet the requirements with improved security notes added 01:44:19 arun has joined #webapps 01:46:07 shiki has joined #webapps 01:46:24 darobin has joined #webapps 02:04:47 Marcos has joined #webapps 02:39:26 Lachy has joined #webapps 02:44:27 Lachy has joined #webapps 03:01:29 mjs_ has joined #webapps 03:03:53 gsnedders has joined #webapps 03:31:16 Nikunj has joined #webapps 03:59:57 Nikunj has joined #webapps 04:00:11 mjs has joined #webapps 04:00:48 Nikunj has left #webapps 04:21:51 timeless_mbp has joined #webapps 04:24:34 Nikunj1 has joined #webapps 04:40:07 Nikunj has joined #webapps 04:49:57 Nikunj has joined #webapps 05:34:13 Nikunj has joined #webapps 05:48:49 Nikunj has joined #webapps 06:23:57 Nikunj has left #webapps 06:46:49 weinig has joined #webapps 06:53:46 timeless_mbp has joined #webapps 07:35:33 annevk has joined #webapps 08:16:22 timeless_mbp has joined #webapps 08:26:05 arve has joined #webapps 09:31:09 shiki has joined #webapps 09:45:26 http://dl.getdropbox.com/u/2400/modernizr-test.html does this match your expectations of support? the tests are _REALLY_ basic. any suggestions would be appreciated 10:10:44 Nikunj has joined #webapps 10:10:50 Nikunj has left #webapps 10:59:15 inimino has joined #webapps 11:06:56 krijnh has joined #webapps 12:58:19 weinig_ has joined #webapps 13:39:04 krijnh has joined #webapps 13:47:17 smaug_ has joined #webapps 14:56:46 aroben has joined #webapps 15:22:22 Nikunj has joined #webapps 15:23:19 arun has joined #webapps 15:58:46 mjs has joined #webapps 16:26:57 annevk has joined #webapps 16:36:46 tlr has joined #webapps 16:38:43 myakura has joined #webapps 16:42:46 Lachy has joined #webapps 16:44:40 Lachy has joined #webapps 16:44:47 darobin has joined #webapps 16:46:03 Lachy has joined #webapps 16:57:03 Nikunj has joined #webapps 17:00:06 ArtB has joined #webapps 17:02:36 MikeSmith has joined #webapps 17:04:07 shepazu has joined #webapps 17:05:51 weinig has joined #webapps 17:06:15 Nikunj has left #webapps 17:07:05 JonathanJ has joined #webapps 17:14:13 JonathanJ has left #webapps 17:19:47 Lachy has joined #webapps 17:39:15 mjs has joined #webapps 17:41:52 shiki has joined #webapps 17:54:30 timeless_mbp has joined #webapps 17:55:32 inimino has joined #webapps 18:13:47 Lachy has joined #webapps 18:18:27 Lachy has joined #webapps 18:18:54 ifette has joined #webapps 18:31:07 weinig has joined #webapps 18:56:15 myakura has joined #webapps 19:01:00 Nikunj has joined #webapps 19:07:00 michaeln has joined #webapps 19:07:41 weinig has joined #webapps 19:30:24 darobin has joined #webapps 19:30:56 tlr has joined #webapps 20:13:19 shepazu has joined #webapps 20:20:29 karl has joined #webapps 20:26:27 tlr has joined #webapps 20:38:16 sicking has joined #webapps 20:41:07 mjs has joined #webapps 20:53:16 sicking has joined #webapps 21:03:08 gsnedders has joined #webapps 21:09:09 Nikunj has joined #webapps 21:27:39 timeless_mbp has joined #webapps 21:29:49 shepazu has joined #webapps 21:37:35 myakura has joined #webapps 21:46:00 shiki has joined #webapps 21:49:49 Lachy has joined #webapps 21:51:53 shiki has joined #webapps 21:53:03 darobin has joined #webapps 21:55:39 Lachy has joined #webapps 21:59:21 shiki_ has joined #webapps 22:00:09 Lachy has joined #webapps 22:09:17 mjs has joined #webapps 22:13:22 weinig has joined #webapps 22:16:04 azunix has joined #webapps 22:23:55 Hixie, not all events are async 22:24:17 i.e. I think .click() is not 22:24:40 or the event dispatched after a sync send() 22:24:43 on XHR 22:36:00 gsnedders has joined #webapps 23:18:58 sicking has joined #webapps 23:36:31 weinig has joined #webapps 23:50:56 Lachy has joined #webapps 00:00:40 weinig has joined #webapps 00:04:08 shiki has joined #webapps 00:06:04 darobin has joined #webapps 00:17:44 sicking has joined #webapps 00:34:19 tlr has joined #webapps 01:09:06 mjs has joined #webapps 01:09:12 weinig has joined #webapps 01:30:35 shiki has joined #webapps 01:56:44 Nikunj has joined #webapps 02:34:05 Nikunj has joined #webapps 04:14:44 Nikunj has joined #webapps 04:40:29 weinig has joined #webapps 05:14:31 Nikunj has joined #webapps 05:42:34 mjs has joined #webapps 06:04:35 weinig has joined #webapps