IRC log of webapps on 2008-10-20
Timestamps are in UTC.
- 07:18:49 [RRSAgent]
- RRSAgent has joined #webapps
- 07:18:49 [RRSAgent]
- logging to http://www.w3.org/2008/10/20-webapps-irc
- 07:19:01 [Carmelo]
- Carmelo has joined #webapps
- 07:20:04 [chaals]
- Agenda: http://www.w3.org/2008/webapps/wiki/WebAppsMandelieuAgenda
- 07:20:14 [chaals]
- Meeting: Web Apps (non-widgets)
- 07:20:45 [marcos]
- marcos has joined #webapps
- 07:21:13 [chaals]
- scribenick: anthony
- 07:21:19 [anthony]
- anthony has left #webapps
- 07:21:25 [dino]
- dino has joined #webapps
- 07:21:50 [anthony_]
- anthony_ has joined #webapps
- 07:24:27 [chaals]
- scribenick: anthony_
- 07:24:58 [anthony_]
- CM: [Chaals introduces himself]
- 07:25:40 [chaals]
- AG: Anthony Grasso, editor of SVG Print
- 07:25:56 [chaals]
- JS: Jonas Sicking
- 07:25:58 [anthony_]
- JS: [Introduce's himself
- 07:26:00 [dino]
- dino has joined #webapps
- 07:26:16 [anthony_]
- AB: [Introduces himself]
- 07:26:26 [anthony_]
- CW: [Introduces himself]
- 07:27:04 [karl]
- karl has joined #webapps
- 07:27:28 [arun]
- arun has joined #webapps
- 07:28:34 [kaz]
- kaz has joined #webapps
- 07:28:36 [anthony_]
- ABat: [Introduces himself]
- 07:28:43 [anthony_]
- EK: [Introduces himself]
- 07:28:45 [kaz]
- kaz has left #webapps
- 07:28:54 [anthony_]
- AV: [Introduces himself]
- 07:29:03 [anthony_]
- WL: [Introduces himself]
- 07:29:12 [anthony_]
- CB: [Introduces himself]
- 07:29:20 [anthony_]
- JR: [Introduces herself]
- 07:29:26 [anthony_]
- NM: [Introduces himself]
- 07:29:38 [anthony_]
- IH: [Introduces himself]
- 07:29:44 [anthony_]
- CM: Agenda has file upload draft
- 07:30:11 [anthony_]
- ... progress events will be done tomorrow
- 07:30:22 [anthony_]
- ... element traversal which we will do today if that's ok DS?
- 07:30:28 [anthony_]
- DS: That's fine
- 07:30:34 [anthony_]
- CM: DOM3 Events?
- 07:30:37 [anthony_]
- DS: Tomorrow?
- 07:31:01 [anthony_]
- CM: XHR1 today
- 07:31:11 [anthony_]
- ... assorted proposals for new work
- 07:31:17 [anthony_]
- ... timers proposal
- 07:31:29 [anthony_]
- ... question of whether workers is done here
- 07:31:36 [anthony_]
- ... we'll have workers for today
- 07:31:46 [anthony_]
- ... Access control for cross site requests
- 07:32:19 [anthony_]
- Topic: File Upload
- 07:32:49 [anthony_]
- AR: Basically I've been working on the file upload spec
- 07:32:55 [anthony_]
- ... there's been some feedback from Apple
- 07:33:09 [anthony_]
- ... mainly just Apple about stating with a more basic set of features
- 07:33:12 [anthony_]
- ... we can agree on
- 07:33:25 [anthony_]
- ... there was feedback from Sync APIs from Mozilla
- 07:33:34 [anthony_]
- ... Google made proposal for Sync APIs
- 07:33:38 [anthony_]
- ... to obtain segments of files
- 07:33:46 [anthony_]
- ... to break them up
- 07:33:59 [anthony_]
- ... there are some concerns with Blog API
- 07:34:23 [anthony_]
- ... Apple wants no I/O
- 07:34:36 [anthony_]
- ... I don't think we will be considering Sync APIs for this spec
- 07:34:45 [anthony_]
- ... I think it will be good to arrive at ASync APIS
- 07:34:59 [anthony_]
- ... have discussions about file dialog
- 07:35:13 [anthony_]
- IH: I think it would be helpful
- 07:35:18 [anthony_]
- ... to come up with a set of requirements
- 07:35:27 [anthony_]
- AR: I didn't get feedback on the list of my requirements
- 07:35:33 [anthony_]
- DS: Did you put them in the wiki?
- 07:35:33 [arve]
- [Question from the next room: why not a traditional file API?]
- 07:35:39 [anthony_]
- AR: They are in the draft
- 07:35:43 [Adam]
- http://dev.w3.org/2006/webapi/FileUpload/publish/FileUpload.xhtml
- 07:35:55 [arun]
- http://dev.w3.org/2006/webapi/FileUpload/publish/FileUpload.xhtml#requirements
- 07:35:58 [anthony_]
- AR: Adam put the right URI
- 07:36:06 [anthony_]
- ... The next link is the requirements
- 07:36:14 [anthony_]
- ... a good place to start is the review of these
- 07:36:36 [anthony_]
- IH: Do you have in mind things like non-file system access
- 07:36:45 [anthony_]
- ... e.g. hook up camera to the video element
- 07:36:59 [anthony_]
- AR: There isn't a good requirement or illustrated use case
- 07:37:09 [chaals]
- q+
- 07:37:20 [anthony_]
- IH: Just want to make sure that you can extend the API
- 07:37:30 [anthony_]
- ... not so much a use case, more so the long term
- 07:37:42 [anthony_]
- ... want to be able to take the video camera the video element
- 07:38:14 [anthony_]
- DS: It's possible that simply doesn't belong in this family of specs
- 07:38:26 [anthony_]
- AR: Maybe possible but I was going to define a Blob interface here
- 07:38:33 [anthony_]
- ... it would at least be one step closer to that
- 07:38:36 [Zakim]
- Zakim has joined #webapps
- 07:38:58 [anthony_]
- ... plus I was to define the HTML file input element interface which would return a file list
- 07:39:07 [anthony_]
- IH: We should interact on that
- 07:39:33 [anthony_]
- JS: I feel like the right technical solution will be to have a stream primitive
- 07:39:47 [nrmehta]
- q+
- 07:39:49 [karl]
- RRSAgent, make log public
- 07:39:52 [anthony_]
- CM: Note that Opera has requirements to do that already
- 07:40:06 [karl]
- rssagent, draft minutes
- 07:40:26 [karl]
- rrsagent, draft minutes
- 07:40:26 [RRSAgent]
- I have made the request to generate http://www.w3.org/2008/10/20-webapps-minutes.html karl
- 07:40:40 [anthony_]
- ... I've been working on draft requirements
- 07:40:58 [anthony_]
- AR: Could this spec define pieces that would be useful to have?
- 07:41:01 [anthony_]
- CM: Potentially
- 07:41:15 [anthony_]
- ... The current proposal for a file API seems limited
- 07:41:20 [anthony_]
- ... we proposed a more complete file API
- 07:41:31 [anthony_]
- ... to give recurring access to the file system
- 07:56:17 [tlr]
- tlr has joined #webapps
- 07:56:38 [kapyaho]
- kapyaho has joined #webapps
- 07:57:29 [dino]
- dino has joined #webapps
- 07:57:33 [karl]
- karl has joined #webapps
- 07:58:11 [arve]
- arve has joined #webapps
- 07:58:47 [dino]
- dino has joined #webapps
- 07:59:16 [wonsuk]
- wonsuk has joined #webapps
- 08:00:12 [Lachy]
- Lachy has joined #webapps
- 08:01:27 [Lachy]
- which IRC channel is this F2F using today?
- 08:01:47 [Hixie]
- this one
- 08:01:51 [gsnedders]
- gsnedders has joined #webapps
- 08:01:59 [Lachy]
- good :-)
- 08:02:20 [MikeSmith]
- MikeSmith has joined #webapps
- 08:05:09 [dino_]
- dino_ has joined #webapps
- 08:05:46 [CWilso]
- CWilso has joined #webapps
- 08:06:16 [arun]
- arun has joined #webapps
- 08:06:20 [chaals]
- chaals has joined #webapps
- 08:06:50 [chaals]
- [connectivity here is very flakey so far - so the logs will be very very randomised]
- 08:07:00 [Adam]
- Adam has joined #webapps
- 08:07:08 [jreyes]
- jreyes has joined #webapps
- 08:07:13 [Carmelo]
- Carmelo has joined #webapps
- 08:07:18 [shepazu]
- shepazu has joined #webapps
- 08:07:41 [sicking]
- sicking has joined #webapps
- 08:08:00 [nrmehta]
- nrmehta has joined #webapps
- 08:08:24 [adrianba]
- adrianba has joined #webapps
- 08:09:25 [anne]
- anne has joined #webapps
- 08:10:24 [anne]
- yay
- 08:11:11 [MikeSmith]
- chaals, shepazu: are you minuting on this channel?
- 08:11:38 [shepazu]
- MikeSmith: yes, but on a 5 minute break atm
- 08:11:46 [MikeSmith]
- OK
- 08:15:47 [marcos]
- marcos has joined #webapps
- 08:17:26 [anthony_]
- anthony_ has joined #webapps
- 08:18:09 [dino]
- dino has joined #webapps
- 08:29:45 [nrmehta]
- nrmehta has joined #webapps
- 08:30:15 [Kangchan]
- Kangchan has joined #webapps
- 08:31:12 [anthony_]
- IH: - Stream
- 08:31:16 [anthony_]
- ... - File
- 08:31:21 [anthony_]
- ... - and file system
- 08:31:30 [anthony_]
- NM: If we move to streams
- 08:31:32 [anthony_]
- ... length is not available
- 08:31:32 [anthony_]
- ... if you upload things that don't have a length
- 08:31:33 [anthony_]
- ... It also involves contact from the server
- 08:31:35 [anthony_]
- ... which are the 3 different requirements
- 08:31:37 [anthony_]
- AR: To Google’s credit the XHR extension that allows severs to send back blogs
- 08:31:39 [anthony_]
- ... this may address your sever side requirement
- 08:31:41 [anthony_]
- NM: My concern was about the length.
- 08:31:54 [anthony_]
- AB: Any file size limitations?
- 08:32:00 [anthony_]
- CM: None. Systems may implement for specific reasons.
- 08:32:07 [anthony_]
- NM: For example I could have video running on my camera
- 08:32:09 [anthony_]
- ... and I could stream that to a server
- 08:32:10 [anthony_]
- ... there is length
- 08:32:13 [anthony_]
- IH: We should treat streams and uploads separately
- 08:32:15 [anthony_]
- ... focus on finite files
- 08:32:17 [anthony_]
- ... what do we expose as Blob API.
- 08:32:21 [anthony_]
- JS: There is also the first question that Apple has is
- 08:32:23 [anthony_]
- ... do they want the Blob API
- 08:32:25 [anthony_]
- ... There is no way of accessing the data
- 08:32:30 [anthony_]
- IH: Makes sense to make incremental steps
- 08:32:37 [anthony_]
- NM: Instead of completely slitting this up. What about creating temporary files on the fly
- 08:32:38 [anthony_]
- ... say I want to capture a picture on my camera and I want to upload it.
- 08:32:40 [anthony_]
- ... Whether it gets saved as a file the user doesn't care.
- 08:32:42 [anthony_]
- ... Would be useful to have an intermediate for the API.
- 08:32:43 [anthony_]
- ... For a while the atom protocol has been out one thing not supported in web browsers is
- 08:32:45 [anthony_]
- ... the ability to upload file from XHR service
- 08:32:47 [anthony_]
- AR: In fact that matches in part of what Apple proposes
- 08:32:49 [anthony_]
- CM: Seems to be the fundamental thing that everyone wants.
- 08:32:51 [anthony_]
- ... Use XHR to upload a file
- 08:33:20 [Adam]
- Adam has joined #webapps
- 08:35:12 [Kangchan]
- Kangchan has left #webapps
- 08:35:57 [arve]
- arve has joined #webapps
- 08:36:45 [anthony_]
- AV: Flikr has an upload widget uses flash. Apples proposal allows replacement of the file object that gives Java control for example.
- 08:36:52 [anthony_]
- AR: This gives an overload of the XHR send
- 08:36:54 [anthony_]
- ... We would be addressing the upload problems in Flikr. Instead of giving another
- 08:36:56 [anthony_]
- ... binary extension to upload.
- 08:36:58 [anthony_]
- ... One of the advantages of non-browser based uploads was you can split the file
- 08:36:59 [anthony_]
- ... up and do chunk uploads. Good for big files.
- 08:37:01 [anthony_]
- ... for XHR you can see the progress.
- 08:37:03 [anthony_]
- IH: What’s the use case
- 08:37:04 [anthony_]
- AB: At Boeing we made something that does large file uploads
- 08:37:06 [anthony_]
- HS: There are also proxies that do that
- 08:37:07 [anthony_]
- IH: You'd want to take a file and split it into max sizes
- 08:37:09 [anthony_]
- AR: Which is the use case
- 08:37:12 [anthony_]
- .. .this brings me back to Step one. I wont be perfectly happy to split out I/O notion of the spec
- 08:37:14 [anthony_]
- ... Apple made points to strip them out.
- 08:37:15 [anthony_]
- ... Apple made the further point that wouldn't be happy with Blob as v1.
- 08:37:17 [anthony_]
- ... I think we should address the main use case which is overloading XHR.
- 08:37:19 [anthony_]
- ... I haven't gotten technical reasons from Apple about why they are not happy with Blob v1.
- 08:37:21 [anthony_]
- CM: My suggestion is given that we are in the stage of being rough draft.
- 08:37:23 [anthony_]
- ... I think we have fairly clear resolution that we want to save the XHR case and
- 08:37:25 [anthony_]
- ... get file input working
- 08:37:26 [anthony_]
- AV: For the changes to XHR I would prefer those changes to happen in XHR.
- 08:37:28 [anthony_]
- AR: I agree with that.
- 08:37:30 [anthony_]
- CM: Is everyone in agreement
- 08:37:32 [anthony_]
- RESOLUTION: That we are indeed aiming to solve the problem to upload a file using XHR
- 08:37:33 [anthony_]
- IH: Is there are reason to have a separate file object and a separate blob object
- 08:37:35 [anthony_]
- AR: Yes, the file deals with the file in its entirety
- 08:37:36 [anthony_]
- IH: The problem arises when you want to upload a partial file
- 08:37:38 [anthony_]
- NM: Not sure what IH's point is the file is not only in bytes but in metadata
- 08:37:41 [anthony_]
- ... why is it useful for uploading the blob?
- 08:37:42 [anthony_]
- JS: A blob is a collection of data where as the file has a content type and file name potentially
- 08:37:44 [anthony_]
- ... both of which you want to send
- 08:37:45 [anthony_]
- ... We would send just the byte stream of the file
- 08:37:47 [anthony_]
- NM: I almost feel it's undefined to upload bytes without a type.
- 08:37:48 [anthony_]
- AR: I agree, as sever app must know what's getting.
- 08:37:50 [anthony_]
- NM: The file includes a Blob. There is clearly overlap there
- 08:37:52 [anthony_]
- HS: How do you get the media type reliably? From an implementation point of view
- 08:37:53 [anthony_]
- JS: We ask the OS. We give it a file and the OS looks it up.
- 08:37:55 [anthony_]
- CM: It's necessarily reliable but it's a common thing
- 08:37:57 [anthony_]
- AR: NM Said there is some redundancies in the interface
- 08:37:59 [anthony_]
- ... unless you invoke the slice method on the blob they may match.
- 08:38:01 [anthony_]
- ... but when you do the properties may vary.
- 08:38:03 [anthony_]
- CM: In the requirements we don't have a particular reason for chunk transferring. Can you give a use case for that?
- 08:38:06 [anthony_]
- AR: Yes.
- 08:38:08 [anthony_]
- ACTION: Arun to add the use case for chunk transfers.
- 08:38:08 [trackbot]
- Created ACTION-258 - Add the use case for chunk transfers. [on Arun Ranganathan - due 2008-10-27].
- 08:38:10 [anthony_]
- AB: We do both directions up and down.
- 08:38:12 [anthony_]
- AR: That's one thing not in this which is a file download of any sort.
- 08:38:15 [anthony_]
- ... so JS has a better use case for file downloads
- 08:38:16 [anthony_]
- JS: For e.g. for Google docs you can open a doc and have it saved to the server. but if you want to save it to the file
- 08:38:19 [anthony_]
- ... system I believe they upload it to the server and give back a URI
- 08:38:21 [anthony_]
- NM: So you are talking about use cases for upload and download?
- 08:38:23 [anthony_]
- JS: So this is for the use case where the user wants to download
- 08:38:25 [anthony_]
- NM: The webforms group has looked at this. I would prefer we leave this out and leave it to forms.
- 08:38:27 [anthony_]
- AR: So HTML5 has resolved to take on Webforms. This may be resolved in HTML5?
- 08:38:29 [anthony_]
- JS: My concern is I don't think it's very form related.
- 08:38:31 [anthony_]
- IH: Most data comes from contentEditable
- 08:38:33 [anthony_]
- JS: I think that if we are created a limited v1 spec that I think download can go into v2
- 08:38:35 [anthony_]
- AR: But it can be a use case/requirement
- 08:38:37 [anthony_]
- JS: If the forms people have looked at this maybe we should look at what they've done. If they have
- 08:38:39 [anthony_]
- ... a good solution we should reference that.
- 08:38:41 [anthony_]
- ACTION: Arun to add a use case for file download
- 08:38:41 [trackbot]
- Created ACTION-259 - Add a use case for file download [on Arun Ranganathan - due 2008-10-27].
- 08:38:43 [anthony_]
- CM: Is anyone desperate to have it v1 spec?
- 08:38:45 [anthony_]
- All: None
- 08:39:44 [jreyes]
- jreyes has joined #webapps
- 08:41:05 [anthony_]
- AR: I believe we can wrap up the discussion
- 08:41:33 [anthony_]
- ... by saying that unless a good technical argument is put forward by Apple
- 08:41:52 [timeless]
- timeless has joined #webapps
- 08:42:12 [anthony_]
- ... I think v1 should include a def of HTML5 file input element, blob as an async
- 08:42:21 [anthony_]
- ... I'm open to removing file dialog
- 08:42:46 [anthony_]
- ... If anyone has any objections regarding Google's blob API speak now
- 08:42:57 [anthony_]
- JS: Right now I'd like to see the sync functionality as async
- 08:43:36 [anthony_]
- CM: Summary, to have the whole thing as a blob API, have the whole thing as ASync, XHR extension and HTML5 input element
- 08:44:03 [anthony_]
- IH: I'm fine with having these features
- 08:44:08 [anthony_]
- ... I think we should make it simpler
- 08:44:19 [anthony_]
- AR: There is a method for removing files
- 08:44:28 [anthony_]
- ... can you give me a technical reason?
- 08:44:33 [anthony_]
- IH: To make it simpler
- 08:44:39 [anthony_]
- CM: What's the complication of removing a file?
- 08:44:56 [anthony_]
- IH: Unless we can absolutely defending having a feature
- 08:45:02 [anthony_]
- ... we should consider dropping it
- 08:45:10 [anthony_]
- AV: Seems like a better approach
- 08:45:14 [anthony_]
- AR: I can remove the remove
- 08:45:20 [anthony_]
- CM: Along with file download
- 08:45:27 [anthony_]
- ... Opera still wants to see file System
- 08:45:43 [anthony_]
- IH: That should also be separate spec like streaming
- 08:45:56 [anthony_]
- CM: Or be v2
- 08:46:07 [anthony_]
- DS: Should put future products in tracker
- 08:46:32 [anthony_]
- ACTION: Chaals to Provide a use case for file system access
- 08:46:32 [trackbot]
- Created ACTION-262 - Provide a use case for file system access [on Charles McCathieNevile - due 2008-10-27].
- 08:46:54 [anthony_]
- CM: With that I think we have enough to go forward
- 08:47:08 [anthony_]
- ... lets drop the proposal to publish the current draft
- 08:47:19 [anthony_]
- ... and you'll do up a new one which you'll propose for publishing
- 08:48:49 [chaals]
- scribeNick: sicking
- 08:49:35 [sicking]
- Topic: new work
- 08:51:05 [sicking]
- CM: current proposals are; stuff from NM, timer API from mjs, workers from whatwg, window API
- 08:51:42 [sicking]
- AR: with worker threads current proposal is to move it from whatwg to w3c to allow parties that prefer working with w3c can contribute
- 08:51:42 [dino]
- dino has joined #webapps
- 08:52:19 [sicking]
- HI: workers are part of w3c
- 08:52:28 [Hixie]
- http://dev.w3.org/html5/workers/Overview.html
- 08:52:41 [sicking]
- AR: propose to make it a formal work item
- 08:52:51 [sicking]
- CM: we need approval from AC
- 08:53:09 [sicking]
- CM: takes not long
- 08:53:28 [sicking]
- CM: need draft, editor
- 08:53:37 [sicking]
- CM: hixie, you wanna be editor?
- 08:53:43 [sicking]
- HI: roxxorz!
- 08:54:14 [arun]
- q+
- 08:54:34 [sicking]
- DS: the reason we need AC approval was that people was worried that webapps was taking on too much
- 08:54:43 [sicking]
- DS: we need usecase and requirements
- 08:54:45 [Hixie]
- s/roxxorz/I'm already editing the spec, so I don't mind changing the SotD to say "WebApps WG" instead of "HTMLWG"
- 08:55:11 [chaals]
- s/roxxorz/I'm already editing the spec, so I don't mind changing the SotD to say "WebApps WG" instead of "HTMLWG"/
- 08:55:43 [nrmehta]
- q-
- 08:56:14 [sicking]
- DS: how long will AC review take?
- 08:56:35 [sicking]
- AC: with this work item it should not take long. 3 weeks i believe
- 08:56:50 [sicking]
- DS: we can start work before AC approves
- 08:57:26 [sicking]
- CM: given that we have editor, anyone think we should not take it on?
- 08:58:02 [sicking]
- RESOLUTION: we will take it to the AC and ask permission to add to charter
- 08:58:25 [sicking]
- DS: we should ask the html wg for permission
- 08:58:53 [sicking]
- CW: as a chair i've said before that i think this is a good idea
- 08:59:26 [sicking]
- CM: it's in our charter that we need to ask AC, but there is no formal process to do so. We'll figure it out
- 09:00:00 [nrmehta]
- http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0104.html
- 09:00:05 [sicking]
- NM: i have proposal for seamless online/offline apps
- 09:00:48 [arun]
- Wants it noted that WorkerThreads was originally requested as a WebApps Work Item, along with Content Security Policy: http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/0416.html
- 09:01:15 [sicking]
- NM: objective is for applications to be able to access data when network is not available. There are a few use cases in draft
- 09:01:17 [arun]
- While WorkerThreads *may* move here as a result of request by Chairs, Content Security Policy still remains TBD (including within Mozilla)
- 09:01:39 [sicking]
- NM: main one is traveling sales guy to access data when not online
- 09:02:26 [sicking]
- NM: html5 proposes new data storage mechanism, such as localstorage or sql db
- 09:02:40 [anne]
- BITSY (with correct MIME type): http://html5.org/temp/2008/bitsy.xhtml
- 09:02:41 [sicking]
- NM: this proposal does not provide a new storage mechanism
- 09:03:06 [sicking]
- NM: you can use XHR to load and store data
- 09:04:06 [sicking]
- NM: you can also use hyper link, form submission, resource links (such as <link>)
- 09:04:55 [sicking]
- NM: caveat is that the data needs to be linked to an atom feed
- 09:05:37 [sicking]
- NM: intention is not to act as a replacement to html5 spec
- 09:05:52 [sicking]
- NM: it's mainly intended for resources, not data
- 09:05:55 [tlr]
- tlr has joined #webapps
- 09:06:30 [chaals]
- s/for resources, not data/for data, not resources (although it could be used for that)/
- 09:06:48 [sicking]
- NM: this proposal provides a way accessing data when offline, and for data to be submitted to server when going back online
- 09:07:38 [sicking]
- AR: does the builder object throw an error if a resource is not available and user is offline?
- 09:08:40 [sicking]
- NM: in such a case the resource will not be available
- 09:09:22 [sicking]
- AR: have you looked at rules for XHR with regards to access to headers
- 09:10:20 [sicking]
- NM: cookie header is allowed to be set in the builder object
- 09:10:27 [sicking]
- AR: are there cross site restrictions
- 09:10:44 [sicking]
- NM: We'd like to allow cross domain access, but we have not thought about that so far
- 09:11:15 [sicking]
- AV: can we back out from technical details and look at higher level
- 09:11:51 [chaals]
- q+
- 09:11:56 [sicking]
- NM: i'd like to able to look at existing objects when offline, and like to be able to change resources while offline
- 09:12:31 [sicking]
- NM: if a resource is not available at request time, request is stored and replayed when resource becomes available
- 09:13:23 [sicking]
- CM: at a very high level this uses atompub to define a synchronization mechanism
- 09:13:48 [CWilso]
- q+: to point out 1) IP 2) "sync is hard"
- 09:13:54 [sicking]
- CM: instead of having to implement your own synch mechanism yourself you use atompub and then let the browser do synchronization for you
- 09:14:01 [chaals]
- ack cha
- 09:14:11 [chaals]
- ack aru
- 09:14:29 [arun]
- q+
- 09:14:52 [sicking]
- NM: html5 has mechanism for storing data. Does not have ability to cache resources
- 09:15:02 [sicking]
- IH: html5 has offline cache
- 09:15:28 [sicking]
- CW: what is the status? It says copyright all rights reserved
- 09:15:52 [sicking]
- CW: sockets does allow this functionality. It's super powerful but also super hard
- 09:16:46 [sicking]
- CW: outlook guys have worked for 10 years to make offline exchange working. It works great now but it was really hard
- 09:17:08 [sicking]
- CM: w3c has process for submitting members only stuff
- 09:17:21 [sicking]
- CW: so is this a member submission?
- 09:18:08 [sicking]
- CW: if it says all rights reserved oracle our guys can't read it
- 09:18:17 [sicking]
- NM: oracle will not have problems making this public
- 09:18:58 [sicking]
- CW: please send it to the list and say that it's a member submission. That'll take care of the license
- 09:19:17 [dino]
- dino has joined #webapps
- 09:19:27 [chaals]
- ACTION: Nikunj to provide a legalese and process-friendly version of the proposal
- 09:19:27 [trackbot]
- Created ACTION-263 - Provide a legalese and process-friendly version of the proposal [on Nikunj Mehta - due 2008-10-27].
- 09:19:42 [sicking]
- JS: very fair, we gave microsoft the same crap when we got feedback under a license
- 09:20:20 [chaals]
- q+ hixie
- 09:20:27 [chaals]
- ack cw
- 09:20:27 [Zakim]
- CWilso, you wanted to point out 1) IP 2) "sync is hard"
- 09:20:31 [sicking]
- NM: since sync is hard we should have functionality for it
- 09:20:54 [sicking]
- CW: we need to look at scenarios before going forward since we will get lots of questions
- 09:21:01 [arun]
- q--
- 09:21:07 [arun]
- q--
- 09:21:09 [sicking]
- CW: we should define use cases clearly
- 09:21:12 [arun]
- q-
- 09:21:29 [sicking]
- NM: we have not included indexing for example
- 09:21:42 [chaals]
- ack hi
- 09:22:58 [chaals]
- q+
- 09:23:21 [sicking]
- IH: my concern is that something like this would be a solution for a small set of problems. Not even 50%. Browsers generally want to address things more like 80% of the use cases
- 09:23:56 [chaals]
- q+ to say that this appears to provide a solution for simple applications, supporting small-time developers, although not enough for really serious applications
- 09:24:25 [CWilso]
- q+ to say: XHR2 + localStorage + SQL storage + this + offline/cache control: whither?
- 09:24:50 [sicking]
- NM: we should have something for atompub. If 80% of atompub are solved by this then this is good enough for us
- 09:24:56 [chaals]
- ack ch
- 09:24:56 [Zakim]
- chaals, you wanted to say that this appears to provide a solution for simple applications, supporting small-time developers, although not enough for really serious applications
- 09:25:05 [sicking]
- IH: this might be implementable using a JS library backed by XHR
- 09:25:33 [arun]
- +1 IH, modulo access to requests from within script
- 09:26:01 [sicking]
- NM: current specs does now allow syncing in background
- 09:26:11 [sicking]
- IH: workers might add that ability, though it scares me
- 09:26:27 [CWilso]
- CM: "idiots like me"
- 09:27:07 [sicking]
- CM: it appears to lower bar for developers to have this functionality
- 09:27:30 [arun]
- q+
- 09:27:32 [sicking]
- CM: if we decide to take this on, we need to look at what the html5 wg
- 09:27:36 [sicking]
- q+
- 09:30:12 [sicking]
- NM: a number of these things are possible to do with existing specs. However there are not conclusive evidence that there is. we did a lot of research on existing specs but wasn't able to find conclusive evidence. If this is interesting enough we probably need to extend specs
- 09:30:53 [CWilso]
- ack cw
- 09:30:53 [Zakim]
- CWilso, you wanted to say: XHR2 + localStorage + SQL storage + this + offline/cache control: whither?
- 09:30:56 [chaals]
- ack cw
- 09:31:00 [sicking]
- NM: for example if the application updates data, there is no mechanism for making that data available to the app itself
- 09:32:22 [sicking]
- CW: it is likely that more advanced use cases we'll point to localstorage etc. It's important that we think of this at a continuum so that it integrates with other pieces
- 09:32:38 [paddy]
- paddy has joined #webapps
- 09:32:56 [chaals]
- s/we'll point to localstorage etc/will roll their own solution based on localstorage, XHR2, etc etc/
- 09:33:03 [sicking]
- CW: i had an action item to look at where offline is going. I was at the time thinking it should stay in html5, but less sure now
- 09:33:34 [arve]
- arve has joined #webapps
- 09:33:39 [MikeSmith]
- RRSAgent, please make minutes
- 09:33:39 [RRSAgent]
- I have made the request to generate http://www.w3.org/2008/10/20-webapps-minutes.html MikeSmith
- 09:34:44 [sicking]
- DS: hixie, what is your opinion on splitting this up into a new WG
- 09:35:07 [paddy]
- paddy has left #webapps
- 09:35:18 [chaals]
- s/new WG/work item in this WG, with a stub in HTML/
- 09:36:15 [shepazu]
- q+
- 09:36:17 [sicking]
- IH: right now integration points are: navigating a browsing context, and when doing general network activity
- 09:36:41 [Hixie]
- ...which is defined just in the appcache step
- 09:37:14 [sicking]
- JS: there is also the markup for declaring manifests
- 09:37:45 [sicking]
- IH: so not the first thing i'd break out, but not the last either
- 09:37:46 [chaals]
- ack ar
- 09:37:53 [sicking]
- q-
- 09:39:11 [chaals]
- q+
- 09:39:49 [sicking]
- AR: if we were to consider this, we should check how much is already covered by existing spec. And we'd need use cases
- 09:40:09 [chaals]
- ack sh
- 09:40:51 [sicking]
- DS: to me this sounds like something that is a larger task that belongs in a larger group, such as a task force or separate WG
- 09:41:16 [sicking]
- CW: i see mixed bag with having separate WG
- 09:41:53 [sicking]
- CW: i'd like a place where the discussion takes place where i can point people
- 09:41:58 [Hixie]
- q+
- 09:42:25 [sicking]
- CW: i wouldn't want to pull anything out from html5 since it's hard to pull too far apart
- 09:43:08 [chaals]
- s/anything/everything/
- 09:43:09 [sicking]
- DS: i can deal with the logistics
- 09:43:22 [chaals]
- ack ch
- 09:43:56 [sicking]
- CM: can i get more work to give to DS plez, kthnx
- 09:44:28 [sicking]
- CM: so he can not do it
- 09:44:39 [sicking]
- CM: simplest way to move forward is to keep in webapps group
- 09:44:49 [sicking]
- CM: needs to be coordinated with html wg
- 09:44:58 [sicking]
- CM: CW, can you follow discussion for webapps
- 09:46:14 [sicking]
- CW: having it in same list is a bit concerning due to traffic volumes
- 09:46:22 [sicking]
- JS: I'd like a separate list too
- 09:47:54 [CWilso]
- q?
- 09:47:56 [CWilso]
- ack hi
- 09:48:02 [sicking]
- CM: NM, are you prepared to do work
- 09:48:11 [sicking]
- s/work/work?/
- 09:48:15 [sicking]
- NM: yes
- 09:48:35 [chaals]
- s/work/the work/
- 09:50:38 [chaals]
- AvK: Want to see the things that can't be done with libraries
- 09:51:03 [nrmehta]
- q+
- 09:51:08 [chaals]
- JS: Think this is something we should look at, but this is a non-trivial problem. E.g. suspect there will be lots of discussions on whether AtomPub is the right thing, etc...
- 09:51:15 [chaals]
- ack nik
- 09:51:39 [chaals]
- JS: also concerned that we will get a 30% solution....
- 09:51:47 [chaals]
- s/will get/may get/
- 09:52:19 [sicking]
- NM: if we approach it as a need to evolve the primitives such that this can be built as a library then that might be a good solution
- 09:52:33 [sicking]
- IH: agree
- 09:52:36 [sicking]
- AV: agree
- 09:52:39 [sicking]
- JS: agree
- 09:54:48 [sicking]
- CM: so sounds like there is agreement to keep looking at problem. First step being gather more use cases, NM has action item to submit some of those
- 09:55:28 [chaals]
- ACTION: Nikunj to provide more use cases and explanation of why we need something like bitsy
- 09:55:28 [trackbot]
- Created ACTION-264 - Provide more use cases and explanation of why we need something like bitsy [on Nikunj Mehta - due 2008-10-27].
- 09:56:08 [sicking]
- CM: do we want to talk about timers?
- 09:56:54 [sicking]
- AV: there are proposals to simply lower the minimum delay from 10ms to 4ms which might address use cases
- 09:57:29 [sicking]
- AV: however we might need to discuss moving setTimeout etc to this wg
- 09:57:33 [sicking]
- s/wg/WG/
- 09:57:38 [sicking]
- JS: who would be editor
- 09:57:58 [sicking]
- AV: opera has a proposed editor
- 09:58:15 [sicking]
- IH: i'd love to see it removed from the html5 spec
- 09:58:37 [sicking]
- CM: shall we resolve to shift spec to webapps
- 09:58:42 [arun]
- +1 AR
- 09:58:55 [sicking]
- IH: i support it as long as there is an editor
- 09:59:21 [arve]
- arve has joined #webapps
- 09:59:23 [sicking]
- RESOLUTION: will start process to get it added as work item for WG
- 10:00:04 [chaals]
- [for all of you reading the logs: "resolutions" here are subject to being published in the minutes, and not raising objections from the group, since not everyone is at this meeting]
- 10:00:16 [sicking]
- Topic: window object
- 10:01:44 [sicking]
- CM: we need an editor
- 10:01:51 [sicking]
- CM: it's really really really hard to edit
- 10:01:57 [sicking]
- CM: you must be insane to do so
- 10:02:02 [sicking]
- CM: anyone interested?
- 10:02:40 [sicking]
- IH: what is the advantage of having it as a separate spec
- 10:03:21 [sicking]
- IH: i used to think it's a good idea, but less sure at this point
- 10:03:55 [sicking]
- IH: I've tried to write the html5 spec such that svg can use it. By defining interactions for for example properties with same name
- 10:04:17 [sicking]
- CM: i'll talk with svg guys and see if anyone is prepared to do the work
- 10:05:07 [sicking]
- IH: i want svg to be able to use it. So tell them if there is anything i can do to help them i'll be happy to do so
- 10:05:28 [sicking]
- CM: anything more we should bring up?
- 10:06:01 [sicking]
- AR: mozilla would like to submit content security policy, but it's not ready at this point. But as a heads up, we'll do so in the future
- 10:06:10 [sicking]
- Topic: lunch
- 10:06:35 [sicking]
- will we have it, and will it taste yummy
- 10:11:59 [chaals]
- We will be back here at 14h30 french time. If you want to talk to another group, before then is a good time to pick
- 11:04:41 [Lachy]
- Lachy has joined #webapps
- 11:42:25 [nrmehta]
- nrmehta has joined #webapps
- 11:49:35 [arve]
- arve has joined #webapps
- 11:51:56 [Adam]
- Adam has joined #webapps
- 11:52:30 [wonsuk]
- wonsuk has joined #webapps
- 11:59:23 [wonsuk]
- wonsuk has joined #webapps
- 11:59:57 [Zakim]
- Zakim has left #webapps
- 12:00:28 [marcos]
- marcos has joined #webapps
- 12:00:53 [Adam]
- Adam has joined #webapps
- 12:01:33 [gsnedders]
- gsnedders has joined #webapps
- 12:06:07 [anthony_]
- anthony_ has joined #webapps
- 12:06:57 [DanC_lap]
- DanC_lap has joined #webapps
- 12:09:07 [DanC_lap]
- (found timbl's proposal http://lists.w3.org/Archives/Public/www-tag/2008May/0165.html )
- 12:09:10 [DanC_lap]
- hierarchical... check.
- 12:10:48 [DanC_lap]
- e.g. <imsg src="../over/there/in/the/zip/file" />
- 12:11:01 [DanC_lap]
- e.g. <img src="../over/there/in/the/zip/file" /> rather
- 12:12:04 [DanC_lap]
- expose... not sure.
- 12:12:15 [DanC_lap]
- outside... not sure
- 12:12:17 [DanC_lap]
- conflict... not sure
- 12:12:21 [hendry]
- hendry has joined #webapps
- 12:13:01 [MikeSmith]
- MikeSmith has joined #webapps
- 12:13:37 [hendry]
- is the widget stuff happening in group 1 or 2?
- 12:13:48 [Lachy]
- Lachy has joined #webapps
- 12:14:03 [hendry]
- and where is the back channel please
- 12:14:16 [DanC_lap]
- (I wonder if http://engine/widget/path is analagous to http://example.com/widgets/2007/blink-01.zip/contents/chrome/js/blink.js . not sure what /engine/ is)
- 12:14:18 [Lachy]
- Lachy has joined #webapps
- 12:14:54 [adrianba]
- adrianba has joined #webapps
- 12:15:10 [DanC_lap]
- "no standard" applies to widget: too, right?
- 12:15:48 [DanC_lap]
- hendry, widget stuff is in A (dunno which is 1 vs 2)
- 12:17:23 [hendry]
- DanC_lap: wondered if i could drop in as an observer for an hour. can't see art online to clear it.
- 12:19:03 [DanC_lap]
- hendry, I just learned #wam is the channel for the widget stuff; ArtB is there
- 12:24:07 [hendry]
- DanC_lap: thanks!
- 12:24:46 [arve]
- arve has joined #webapps
- 12:27:37 [gsnedders]
- I guess I should return to the room
- 12:29:36 [CWilso]
- CWilso has joined #webapps
- 12:35:24 [anne]
- anne has joined #webapps
- 12:37:58 [tlr]
- tlr has joined #webapps
- 12:40:56 [sicking]
- sicking has joined #webapps
- 12:50:12 [adrianba]
- adrianba has joined #webapps
- 12:51:43 [nrmehta]
- nrmehta has joined #webapps
- 12:53:40 [arun]
- arun has joined #webapps
- 12:55:06 [Adam]
- Adam has joined #webapps
- 12:55:38 [Adam]
- scribeNick: Adam
- 12:56:01 [Adam]
- Topic: Element Traversal
- 12:56:03 [ed_fr]
- ed_fr has joined #webapps
- 12:56:12 [chaals]
- chaals has joined #webapps
- 12:56:44 [Lachy]
- just so this is recorded somewhere, even though it's not the topic yet, the remaining issues for selectors api are:
- 12:56:44 [Lachy]
- 1. Add last 40 emails to the disposition of comments
- 12:56:44 [Lachy]
- 2. deal with one issue regarding the feature string/
- 12:56:44 [Lachy]
- 3. Respond to other emails saying that the issues are postponed till v2.
- 12:57:37 [Adam]
- DS: you can skip over text nodes and just navigate the tree by the elements
- 12:57:51 [Adam]
- wrote some tests, has been CR
- 12:58:03 [chaals]
- [chaals uploaded a new progress events draft: http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.22 for your enjoyment]
- 12:58:08 [Adam]
- DS: wrote some tests, has been CR
- 12:58:54 [Adam]
- DS: html 4, xhtml, etc versions of the files, tested in opera and batik which is an svg toolkit
- 12:59:08 [MoZ]
- MoZ has joined #webapps
- 12:59:16 [chaals]
- s/etc versions/svg versions/
- 12:59:17 [Adam]
- DS: each test passed by both opera and svg toolkit,
- 12:59:32 [Adam]
- DS: would like to propose moving from CR to PR
- 12:59:43 [Adam]
- JS: sold
- 13:00:23 [Adam]
- JS: test cases do have some errors
- 13:00:45 [Adam]
- JS: etnamespace.svg test
- 13:01:02 [smaug]
- chaals: could you change loaded and total to unsigned long long?
- 13:01:38 [chaals]
- [smaug, I think I did that]
- 13:01:58 [Adam]
- AV: would like to see it test
- 13:01:59 [shepazu]
- http://dev.w3.org/2006/webapi/ElementTraversal/tests/
- 13:02:00 [smaug]
- "readonly attribute unsigned long loaded;"
- 13:02:13 [sicking]
- http://dev.w3.org/2006/webapi/ElementTraversal/tests/et-namespace.svg
- 13:02:41 [chaals]
- [ah. found it... Better edited version coming soon]
- 13:02:47 [Adam]
- DS: were very basic test
- 13:03:02 [Adam]
- JS: are you testing dynamic stuff
- 13:03:04 [Adam]
- DS: no
- 13:03:34 [Adam]
- JS: will try to update his test, does some dynamic stuff
- 13:03:48 [Adam]
- JS: haven't tested any of the HTML test
- 13:04:31 [Adam]
- DS: should see the word pass if they pass
- 13:05:59 [Adam]
- AV: where is the function init test being called
- 13:06:08 [Adam]
- AV: doesn't seem to run the script at all?
- 13:07:39 [Adam]
- DS: thought other people wanted some things for version 2
- 13:08:31 [anne]
- ed_fr, I pointed out as much
- 13:08:40 [anne]
- ed_fr, the tests suck, for lack of a better word
- 13:08:45 [Adam]
- CM: we believe when the tests are fixed they'll pass, that their modular, bugs identified, assuming when the tests are fixed, and the browsers pass it we are resolved to PR status
- 13:09:29 [chaals]
- RESOLUTION: Subject to the identified bugs in tests being fixed, and implementations still passing, we will request PR status for Element Traversal
- 13:10:00 [Adam]
- AV: still think its not necessary to child element counts
- 13:10:07 [Adam]
- DS: likes it
- 13:10:22 [Hixie]
- is the next topic xhr?
- 13:10:23 [Adam]
- AV: whats wrong with children length
- 13:10:46 [Hixie]
- thanks
- 13:10:54 [anne]
- children.length is two characters shorter than childElementCount
- 13:10:55 [Adam]
- DS: it was svg to tiny user agent with mobile devices that don't already have node list interface
- 13:11:21 [Adam]
- DS: feedback from user agent vendors didn't want to do node list, that operation was significantly more costly to them
- 13:11:35 [Adam]
- DS: could be put in v2
- 13:11:48 [Adam]
- JS: totally bogus but not going to argue about it
- 13:11:53 [Adam]
- AV: agree it's bogus
- 13:12:52 [Adam]
- CM: if we stop talking about this we'll have more time to talk about v2
- 13:13:11 [Adam]
- JS: for the sake of moving on
- 13:14:10 [Adam]
- DS: moving on to v2
- 13:14:30 [chaals]
- ACTION: Doug to fix the tests for Element Traversal and make the implementation report
- 13:14:30 [trackbot]
- Sorry, amibiguous username (more than one match) - Doug
- 13:14:30 [trackbot]
- Try using a different identifier, such as family name or username (eg. dstamper, schepers)
- 13:14:40 [chaals]
- ACTION: schepers to fix the tests for Element Traversal and make the implementation report
- 13:14:40 [trackbot]
- Created ACTION-266 - Fix the tests for Element Traversal and make the implementation report [on Doug Schepers - due 2008-10-27].
- 13:15:15 [Adam]
- CM: do we need AC approval to do v2
- 13:15:29 [Adam]
- AV: seems unnecessary
- 13:15:53 [chaals]
- ACTION: schepers to check if we need approval to work on Element Traversal, and start working on v. 2
- 13:15:53 [trackbot]
- Created ACTION-267 - Check if we need approval to work on Element Traversal, and start working on v. 2 [on Doug Schepers - due 2008-10-27].
- 13:15:59 [Adam]
- AV: no need for an email to 400 people for people to say yes
- 13:16:03 [Adam]
- DS: doesn't agree
- 13:16:17 [Adam]
- DS: want to let them know we're doing work
- 13:18:34 [Adam]
- JS: thought wanted following children on text nodes
- 13:18:43 [Adam]
- JS: thougth somebody asked for that
- 13:19:22 [Adam]
- JS: point was should be in v2 and not in a separate space
- 13:19:23 [chaals]
- RESOLUTION: We want the new version with node lists etc...
- 13:19:37 [Adam]
- Topic: XHR
- 13:20:35 [shepazu]
- s/following children/next-previousElementSibling/
- 13:20:43 [Adam]
- AV: was comment made on last call, made some disposition of comments
- 13:20:50 [Adam]
- AV: need some kind of wg agreement
- 13:21:16 [Adam]
- AV: HS mentioned might be something in html5
- 13:21:33 [Adam]
- AV: actually doing the XHR actually integrate in to the event loop
- 13:21:44 [Adam]
- CM: why do we want to make this change
- 13:22:05 [Adam]
- HS: if you do a set timeout or trigger or an async event it defines in what order the events will fire
- 13:22:21 [Adam]
- AV: that is a part that has never been standardized but html5 does that
- 13:22:27 [Adam]
- AV: a few hours to do
- 13:22:47 [Adam]
- HS: net change spec will say fire task
- 13:23:31 [Adam]
- AV: that was the only to change in v1, v2 has other oustanding issues
- 13:23:56 [Adam]
- JS: at the risk of starting a war, what were the prospects of ie implementing the spec
- 13:24:45 [Adam]
- JS: feels the pain of it breaking stuff in IE
- 13:24:58 [Adam]
- JS: is there a strategy here to get everyone on the same page
- 13:25:59 [Adam]
- CW: great guestions, i don't know, last understanding was there where things being done differently, not going to be able to change it in the near term, not say we shouldn't or it's not the right thing to do
- 13:26:17 [Adam]
- JS: what is the probabity of it eventually being implemented
- 13:26:21 [Adam]
- CW: it's not impossible
- 13:26:38 [Adam]
- JS: is there feedback from MS on things that should be changed in the spec
- 13:27:09 [Adam]
- ABate: does have a document that he has the action to review that but not sure what it has
- 13:27:50 [Adam]
- CM: seems like there are least some changes to spec so not going to do a last call today
- 13:28:18 [Adam]
- AV: don't have any open issues noted
- 13:28:54 [Adam]
- AV: some issue with char set that he doesn't have the detail down for yet
- 13:29:08 [Adam]
- JS: is afraid of changing the content type at all
- 13:29:21 [Adam]
- JS: why is that in the spec
- 13:29:29 [Adam]
- AV: somebody argued for it
- 13:29:39 [Adam]
- AV: so the server could figure out whats going on
- 13:29:39 [chaals]
- [ http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.23 available, with better editing (Thanks Smaug)]
- 13:30:04 [Adam]
- JS: personally wouldn't might waiting for that until XHR2
- 13:30:20 [Adam]
- AV: doesn't want to add a dom attribute
- 13:30:26 [Adam]
- AV: to address it
- 13:30:48 [Adam]
- JS: alternative is to have a separate header
- 13:31:46 [smaug]
- [chaals: still "readonly attribute unsigned long loaded;" ;) ]
- 13:32:00 [smaug]
- [same for .total]
- 13:32:59 [Adam]
- AV: i really hate char sets
- 13:33:24 [Adam]
- AV: could leave it undefined, i don't like it, could say sending char set is a violation
- 13:33:46 [chaals]
- [d'oh. /me curses whitespace and fixes it AGAIN...]
- 13:34:00 [Adam]
- AV: could let MS and JS to go back for feedback review
- 13:34:13 [Adam]
- Action: JS to review if char set is something that can be removed
- 13:34:13 [trackbot]
- Sorry, amibiguous username (more than one match) - JS
- 13:34:13 [trackbot]
- Try using a different identifier, such as family name or username (eg. jsoref, jsicking)
- 13:34:28 [nrmehta]
- This is a common problem with charsets on XML and HTTP http://www.xml.com/pub/a/2004/07/21/dive.html
- 13:34:30 [Adam]
- Action: jsicking to review if char set is something that can be removed
- 13:34:30 [trackbot]
- Created ACTION-268 - Review if char set is something that can be removed [on Jonas Sicking - due 2008-10-27].
- 13:35:41 [Adam]
- AV: did we want to go through comments for disposition
- 13:36:00 [Adam]
- HS: should go through the ones where the commentor is not happy with the response
- 13:36:21 [anne]
- http://dev.w3.org/2006/webapi/XMLHttpRequest/disposition-of-comments-2
- 13:36:57 [DanC_lap]
- [15:37] <trackbot>ACTION-187 -- Dan Connolly to talk with TimBL about install-time names for widgets -- due 2008-10-27 -- OPEN
- 13:36:57 [DanC_lap]
- [15:37] <trackbot>http://www.w3.org/2001/tag/group/track/actions/187
- 13:37:38 [chaals]
- [aah, smaug were you looking at http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.24 ? I may have pasted the wrong link in before ;) ]
- 13:37:52 [Adam]
- CM: don't have to look at all the dispositions from previous last call
- 13:38:12 [Adam]
- AV: #7 is rejected
- 13:38:28 [Adam]
- AV: several headers are being blocked on being sent
- 13:38:50 [smaug]
- [chaals: great, thanks. Will change long -> long long in mozilla]
- 13:38:53 [Adam]
- AV: he agrees with some being blocked but not others
- 13:39:30 [Adam]
- DS: have other people chimed in on that thread, is there some sort of
- 13:39:49 [Adam]
- HS: can't allow the user agent is dodgy
- 13:39:52 [anne]
- http://lists.w3.org/Archives/Public/public-webapi/2008May/0408.html
- 13:40:50 [Adam]
- AV: some reason why referrer was on the block list
- 13:40:57 [Adam]
- JS: i don't think we block it yet do we
- 13:41:59 [Adam]
- DS: he is not an implementor
- 13:42:25 [Adam]
- DS: does anybody in the group disagree with AV
- 13:42:44 [Adam]
- DS: if the vendors are all ok then this is a polite disagree
- 13:43:26 [Adam]
- AV: was about the dependancy on html 5
- 13:44:29 [Adam]
- CM: lots of people said strip the reference to html5
- 13:44:47 [Adam]
- AV: they suggested to copy it all in, that was not the best way to go, would be huge
- 13:45:06 [Adam]
- DS: i requested the spec leave everything up to the host language
- 13:45:15 [Adam]
- AV: what is a host language?
- 13:45:29 [Adam]
- DS: if you're using a script it's the host language
- 13:45:49 [Adam]
- HS: bigger problem is you may not have a host language
- 13:46:00 [Adam]
- DS: that would be the host language
- 13:46:05 [MikeSmith]
- q?
- 13:46:08 [Adam]
- HS: then that would be the host language
- 13:46:38 [Zakim]
- Zakim has joined #webapps
- 13:46:46 [Adam]
- AV: some definitions could be inlined
- 13:46:55 [wonsuk]
- wonsuk has joined #webapps
- 13:47:32 [Adam]
- HS: there is a reference from html 5 to xhr in that part of the spec
- 13:48:44 [Adam]
- JS: can do cross domain at the browser chrome
- 13:48:57 [Adam]
- AV: could be a should do it
- 13:49:20 [Adam]
- JS: why do we need to specifiy that xhr is same origin
- 13:49:28 [Adam]
- AV: still need to define origin
- 13:50:29 [Adam]
- CM: would suggest that things that can be inlined are better off inlined
- 13:50:49 [Adam]
- CM: makes the case these things are massive complicated stuff makes the case easier to argue
- 13:51:13 [Adam]
- Action: chaals to look through the references to see what can reasonably inlined
- 13:51:13 [trackbot]
- Created ACTION-269 - Look through the references to see what can reasonably inlined [on Charles McCathieNevile - due 2008-10-27].
- 13:52:07 [Adam]
- AV: is ok with doing this
- 13:53:54 [Adam]
- AV: one issue with setting second arg to null
- 13:54:07 [Adam]
- JS: null handling is behavior is undefined
- 13:55:02 [kapyaho]
- kapyaho has joined #webapps
- 13:55:10 [Hixie]
- chaals, do you remember which section of the process defines this restriction on references? i can't find it (i wanted to see what the exact wording is)
- 13:55:48 [Adam]
- JS: have 2 options, it gives special behavior for null, or do nothing
- 13:56:03 [Adam]
- AV: default is stringify to default
- 13:56:14 [Adam]
- JS: i think should leave it at the default
- 13:57:02 [nrmehta]
- q+
- 13:57:39 [Adam]
- HS: can't just leave it the default
- 13:58:45 [Adam]
- JS: a little afraid of doing any behavior even though it sounds somewhat reasonable to do
- 13:59:01 [Adam]
- CM: julian is the only one that wants to remove the header
- 13:59:22 [Adam]
- NM: value null is issue if you stringify it
- 13:59:34 [Adam]
- NM: there are no sementics defined for the value null
- 13:59:56 [Adam]
- NM: agree with JS
- 14:00:14 [chaals]
- Hixie, can't recall off hand.
- 14:00:21 [Adam]
- HS: would much rather browser turn it in to empty string
- 14:01:43 [Adam]
- JS: would like it be explicitly undefined here
- 14:01:48 [Adam]
- AV: thats not possible
- 14:02:39 [nrmehta]
- null causes more problems if one were to call setRequestHeader multiple times to set values of the same header, in which case the value null will be serialized in to the concatenated header value
- 14:02:49 [Adam]
- JS: things follow what web idl says to do
- 14:02:57 [Adam]
- AV: i don't think we should do that
- 14:03:40 [Hixie]
- sicking, http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/Overview.html?content-type=text/html;%20charset=utf-8
- 14:03:56 [Hixie]
- sicking: search for the third definition of "open(" in the IDL
- 14:04:08 [Hixie]
- and compare the second and the third arguments
- 14:04:34 [Adam]
- NM: in opinion, thinks it's in violation of the spec
- 14:06:33 [Adam]
- CM: should we do what julian says and remove the header? in any case no, not goign to remove the headers
- 14:06:43 [Adam]
- Resoultion: not going to remove the header
- 14:06:53 [Adam]
- Resolution: not going to remove the header
- 14:07:06 [anthony__]
- anthony__ has joined #webapps
- 14:07:07 [karl]
- karl has joined #webapps
- 14:07:42 [karl]
- Hixie, chaals there is no formal requirement in the process document, but
- 14:07:56 [Adam]
- taking a break
- 14:07:57 [karl]
- if you go to http://www.w3.org/2005/08/online_xslt/xslt?xmlfile=http://www.w3.org/2005/08/01-transitions.html&xslfile=http://www.w3.org/2005/08/transitions.xsl&docstatus=pr-tr
- 14:08:30 [karl]
- there is
- 14:08:31 [karl]
- Evidence that dependencies with other groups met (or not)
- 14:08:31 [karl]
- * Does this specification have any normative references to W3C specifications that are not yet Proposed Recommendations? Note: In general, documents do not advance to Recommendation with normative references to W3C specifications that are not yet Recommendations.
- 14:08:31 [karl]
- * Is there evidence that additional dependencies related to implementation have been satisfied?
- 14:08:47 [Hixie]
- hm, interesting
- 14:08:55 [Hixie]
- so it's not a process issue?
- 14:09:49 [karl]
- not realy, it is more that if a document has a normative dependency on another one. it is risky.
- 14:09:58 [karl]
- the referenced document can change
- 14:10:08 [karl]
- changing then the conformance requirement.
- 14:10:15 [karl]
- I guess it is case by case
- 14:10:28 [karl]
- and has to be strongly documented when going to the transition call.
- 14:10:47 [Hixie]
- very interesting
- 14:10:48 [Hixie]
- thanks!
- 14:10:53 [karl]
- your welcome
- 14:11:05 [karl]
- s/your/you're/
- 14:11:34 [tlr]
- tlr has joined #webapps
- 14:12:19 [wonsuk]
- wonsuk has left #webapps
- 14:13:20 [wonsuk]
- wonsuk has joined #webapps
- 14:18:15 [chaals]
- chaals has joined #webapps
- 14:19:21 [kapyaho_]
- kapyaho_ has joined #webapps
- 14:20:16 [aroben]
- aroben has joined #webapps
- 14:25:32 [MikeSmith]
- RRSAgent, make minutes
- 14:25:32 [RRSAgent]
- I have made the request to generate http://www.w3.org/2008/10/20-webapps-minutes.html MikeSmith
- 14:26:02 [CWilso]
- scribenick: cwilso
- 14:28:19 [shepazu]
- shepazu has joined #webapps
- 14:28:35 [gsnedders]
- gsnedders has joined #webapps
- 14:28:37 [kapyaho]
- kapyaho has joined #webapps
- 14:29:10 [CWilso]
- Topic: XHR still
- 14:30:50 [CWilso]
- JS: HTTP-only key issue. thinks moz is going to block set-cookie header entirely.
- 14:31:41 [Hixie]
- http://dev.w3.org/2006/webapi/XMLHttpRequest/disposition-of-comments-2
- 14:32:11 [CWilso]
- AVK: you're suggesting not getting any value back for setcookie? That would be cool...
- 14:32:29 [nrmehta]
- q+
- 14:32:50 [CWilso]
- JS: yes, we pretend like it's not there. There's some concern about breakage, but seems unlikely.
- 14:35:30 [CWilso]
- IH: realm seems ok, since you can get it from the url.
- 14:35:39 [MoZ]
- MoZ has joined #webapps
- 14:36:21 [gsnedders]
- gsnedders has joined #webapps
- 14:36:52 [CWilso]
- NM: list of headers is static... but there's nothing here that requires browser impls to sync with IETF list of headers - what happens if someone defines a new header?
- 14:37:03 [CWilso]
- JS: don't do that. Or use Sec-.
- 14:39:32 [CWilso]
- AVK: Next issue: forms wg requested making instantiating an XHR object more abstract (e.g. don't need a Window object)
- 14:39:47 [CWilso]
- JS: XHR would make sense for Flash, but they don't have Window.
- 14:39:56 [CWilso]
- AVK: why do we care about Flash
- 14:40:00 [CWilso]
- ack NM
- 14:40:04 [CWilso]
- ack NR
- 14:40:25 [CWilso]
- JS: seems like we should make this possible
- 14:41:58 [arve]
- arve has joined #webapps
- 14:43:22 [CWilso]
- (discussion of proprietary platforms using XHR ensues)
- 14:46:09 [CWilso]
- IH: should just make the magic sentence non-normative
- 14:46:44 [maxf]
- maxf has joined #webapps
- 14:47:09 [CWilso]
- ACTION: Jonas Sicking to send email: Make non-normative suggestion that Window object can be omitted (for situations with no Window)
- 14:47:09 [trackbot]
- Created ACTION-270 - Sicking to send email: Make non-normative suggestion that Window object can be omitted (for situations with no Window) [on Jonas Sicking - due 2008-10-27].
- 14:47:44 [CWilso]
- AVK: That's it for XHR1
- 14:48:49 [CWilso]
- JS: XHR1 says to send the same events whether you're synchronous or async. Mozilla doesn't currently send any events in sync case. Is the spec right here?
- 14:49:06 [CWilso]
- AVK: Yes. I have tests for this and moz fails them.
- 14:49:46 [shepazu]
- Element Traversal implementation report: http://dev.w3.org/2006/webapi/ElementTraversal/tests/report/et-implementationReport.html
- 14:50:12 [CWilso]
- AVK: the events are fired synchronously.
- 14:50:21 [CWilso]
- [discussion ensues of whether this is true]
- 14:52:54 [CWilso]
- IH: why can't you skip events?
- 14:53:11 [CWilso]
- JS: because we put lots of other stuff in the event loop, including the UI
- 14:53:44 [CWilso]
- IH: from my point of view, that's a bug
- 14:53:52 [CWilso]
- JS: from my point of view, it's a feature. :)
- 14:56:32 [CWilso]
- IH: we can (should?) change the spec to explicitly state that we keep pumping the event loop during sync XHR
- 14:58:06 [marcos]
- marcos has joined #webapps
- 15:01:01 [CWilso]
- AVK: will leave spec as is
- 15:01:40 [gsnedders]
- gsnedders has joined #webapps
- 15:02:43 [CWilso]
- AVK: that concludes addressing the comments
- 15:03:14 [CWilso]
- AVK: will update Disposition of comments.
- 15:05:00 [CWilso]
- Topic: Selectors api
- 15:05:01 [Lachy]
- http://dev.w3.org/2006/webapi/selectors-api/
- 15:05:45 [CWilso]
- LH: spec update is mostly done, almost ready to go to 2nd LC. About 40 emails to go through for Disposition of Comments.
- 15:07:31 [CWilso]
- Last issue is the Feature string (hasFeature)
- 15:07:57 [CWilso]
- LH: rejected request to use XHTML syntax for example
- 15:09:45 [CWilso]
- LH: adding "scope" - moved to v2
- 15:13:16 [CWilso]
- LH: [number of issues relating to NSResolver, which was dropped]
- 15:13:59 [CWilso]
- MS: So three weeks or so for a new LC draft?
- 15:14:55 [CWilso]
- JS: defends namespaces
- 15:16:44 [CWilso]
- JS: I think we'll end up adding back NSResolver as it was
- 15:17:09 [CWilso]
- JS: but I'm fine with it not being in v1.
- 15:18:45 [CWilso]
- LH: need to fix up the list of acknowledgements.
- 15:19:19 [CWilso]
- AVK: proposes to publish LC again
- 15:19:41 [CWilso]
- hearing no object, MS says:
- 15:19:49 [CWilso]
- s/object/objections
- 15:20:08 [MikeSmith]
- RESOLUTION: Publish another LC WD for Selectors API, with plan to do 3-week LC period.
- 15:20:36 [CWilso]
- MS: tomorrow: AC, XHR2, Progress Events
- 15:23:20 [CWilso]
- IH: Window should contain browsing context and navigating context
- 15:24:11 [MikeSmith]
- i/Window should/Topic: Moving forward with Window Object spec?/
- 15:24:42 [CWilso]
- yeah, something like that.
- 15:25:52 [CWilso]
- MS: seems like we should be done for the day?
- 15:26:03 [CWilso]
- adjourned
- 15:26:06 [ArtB]
- ArtB has joined #webapps
- 15:26:08 [CWilso]
- RRSAgent, make minutes
- 15:26:08 [RRSAgent]
- I have made the request to generate http://www.w3.org/2008/10/20-webapps-minutes.html CWilso
- 15:27:48 [MikeSmith]
- back tomorrow at 9am
- 15:27:56 [gsnedders]
- <http://www.w3.org/2008/10/TPAC/Schedule.html> says groups at 8:30
- 15:28:00 [gsnedders]
- But I'd like breakfast.
- 15:28:12 [MikeSmith]
- thanks to everybody who scribed
- 15:35:24 [marcos]
- marcos has joined #webapps
- 15:38:43 [anthony]
- anthony has joined #webapps
- 15:54:42 [harry]
- harry has joined #webapps
- 16:12:09 [MoZ]
- MoZ has joined #webapps
- 16:13:32 [mjs]
- mjs has joined #webapps
- 16:38:46 [adrianba]
- adrianba has joined #webapps
- 17:04:01 [Zakim]
- Zakim has left #webapps
- 19:43:11 [DanC_lap]
- DanC_lap has joined #webapps
- 20:36:04 [DanC_lap]
- DanC_lap has joined #webapps
- 20:44:17 [anne]
- anne has joined #webapps
- 21:11:36 [arve]
- arve has joined #webapps
- 23:03:35 [heycam]
- heycam has joined #webapps
- 23:05:24 [nrmehta]
- nrmehta has joined #webapps