Re: Use Cases for Connectionless Push support in Webapps recharter
Hi All, With respect to the charter, the SSE snippet currently says: [[ Server-Sent Events - An API for opening an HTTP connection for receiving push notifications from a server in the form of DOM events. The API is designed such that it can be extended to work with other push notification schemes such as Push SMS. ]] Is the above sufficient to cover the UCs Bryan proposes? If not, what specific change(s) is needed? Hixie - what are your thoughts on these UCs and how they would be spec'ed? For example, would they be in a different spec, an L.next type spec? (FYI, the minutes from November 1 discussion [that I did not attend] are http://www.w3.org/2011/11/01-webapps-minutes.html#item10). -AB On 1/3/12 6:51 PM, ext Bryan Sullivan wrote: I had an action item to provide some use cases for the Webapps recharter process, related to the Push based on extending server-sent events topic at the last F2F (draft API proposal that was presented: http://bkaj.net/w3c/eventsource-push.html). The intent of the action item was to establish a basis for a Webapps charter item related to extending eventsource (or coming up with a new API) for the ability to deliver arbitrary notifications/data to webapps via connectionless bearers, as informationally described in Server-Sent Events (http://dev.w3.org/html5/eventsource/). Here are three use cases: 1) One of Bob’s most-used apps is a social networking webapp which enables him to remain near-realtime connected to his friends and colleagues. During his busy social hours, when he’s out clubbing, his phone stays pretty much connected full time, with a constant stream of friend updates. He likes to remain just as connected though during less-busy times, for example during the workday as friends post their lunch plans or other updates randomly. While he wants his favorite app to remain ready to alert him, he doesn’t want the app to drain his battery just to remain connected during low-update periods. 2) Alice is a collector, and is continually watching or bidding in various online auctions. When auctions are about to close, she knows the activity can be fast and furious and is usually watching her auction webapp closely. But in the long slow hours between auction closings, she still likes for her webapp to alert her about bids and other auction updates as they happen, without delay. She needs for her auction webapp to enable her to continually watch multiple auctions without fear that its data usage during the slow periods will adversely impact her profits. 3) Bob uses a web based real-time communications service and he wants to be available to his friends and family even when his application is not running. Bob travels frequently and it is critical for him to optimize data usage and preserve battery. Bob’s friends can call him up to chat using video/audio or just text and he wants to make sure they can reach him irrespective of what device and what network he is connected at any given time. Comments/questions?
RE: to add Speech API to Charter; deadline January 19
Olli has a good point that it makes sense to implement the SpeechAPI in pieces. That doesn't mean that the WebApps WG only has to look at one proposal in deciding how to proceed with the work. Another option would be to start off the Speech API work in the Web Apps group with both proposals (the Google proposal and the SpeechXG report) and let the editors prioritize the order that the different aspects of the API are worked out and published as specs. -Original Message- From: Satish S [mailto:sat...@google.com] Sent: Thursday, January 12, 2012 5:01 PM To: Young, Milan Cc: Arthur Barstow; public-webapps; public-xg-htmlspe...@w3.org Subject: Re: to add Speech API to Charter; deadline January 19 Milan, It looks like we fundamentally agree on several things: * That we'd like to see the JavaScript Speech API included in the WebApps' charter.* That we believe the wire protocol is best suited for another organization, such as IETF.* That we believe the markup bindings may be excluded. Our only difference seems to be whether to start with the extensive Javascript API proposed in [1] or the simplified subset of it proposed in [2] which supports majority of the use cases in the XGs Final Report. Art Barstow asked for a relatively specific proposal and provided some precedence examples regarding the level of detail. [3] Olli Pettay wrote in [4] Since from practical point of view the API+protocol XG defined is a huge thing to implement at once, it makes sense to implement it in pieces. Starting with a baseline that supports the majority of use cases will accelerate implementation, interoperability testing, standardization and ultimately developer adoption. Cheers Satish [1] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/[2] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att- 1696/speechapi.html[3] http://lists.w3.org/Archives/Public/public- webapps/2011OctDec/1474.html[4] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0068.html On Thu, Jan 12, 2012 at 5:46 PM, Young, Milan milan.yo...@nuance.com wrote: I've made the point a few times now, and would appreciate a response. Why are we preferring to seed WebApps speech with [2] when we already have [3] that represents industry consensus as of a month ago (Google not withstanding)? Proceeding with [2] would almost surely delay the resulting specification as functionality would patched and haggled over to meet consensus. My counter proposal is to open the HTML/speech marriage in WebApps essentially where we left off at [3]. The only variants being: 1) Dropping the markup bindings in sections 7.1.2/7.1.3 because its primary supporter has since expressed non-interest, and 2) Spin the protocol specification in 7.2 out to the IETF. If I need to formalize all of this in a document, please let me know. Thank you [3] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/ -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Thursday, January 12, 2012 4:31 AM To: public-webapps Cc: public-xg-htmlspe...@w3.org Subject: CfC: to add Speech API to Charter; deadline January 19 Glen Shires and some others at Google proposed [1] that WebApps add Speech API to WebApps' charter and they put forward the Speech Javascript API Specification [2] as as a starting point. Members of Mozilla and Nuance have voiced various levels of support for this proposal. As such, this is a Call for Consensus to add Speech API to WebApps' charter. Positive response to this CfC is preferred and encouraged and silence will be considered as agreeing with the proposal. The deadline for comments is January 19 and all comments should be sent to public- webapps at w3.org. -AB [1] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1696.html [2] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att- 1696/s peechapi.html
RE: to add Speech API to Charter; deadline January 19
That's exactly the right question to ask. Please take a look at: http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech-20111206/#requirements I am also in support of Olli's statement that we may not be able to spec/implement the complete XG recommendation in one pass. But decisions made toward the definition of that initial feature set should be made in a democratic forum. I feel the best way to do that is to start where the last democratic forum left off, and whittle down from there as schedule requires. Thank you -Original Message- From: Dave Bernard [mailto:dbern...@intellectiongroup.com] Sent: Friday, January 13, 2012 8:14 AM To: 'Deborah Dahl'; 'Satish S'; Young, Milan Cc: 'Arthur Barstow'; 'public-webapps'; public-xg-htmlspe...@w3.org Subject: RE: to add Speech API to Charter; deadline January 19 Deborah- Is there a draft priority list in existence? I like the idea of getting good enough out there sooner, especially as an implementer with real projects in the space. Dave -Original Message- From: Deborah Dahl [mailto:d...@conversational-technologies.com] Sent: Friday, January 13, 2012 10:43 AM To: 'Satish S'; 'Young, Milan' Cc: 'Arthur Barstow'; 'public-webapps'; public-xg-htmlspe...@w3.org Subject: RE: to add Speech API to Charter; deadline January 19 Olli has a good point that it makes sense to implement the SpeechAPI in pieces. That doesn't mean that the WebApps WG only has to look at one proposal in deciding how to proceed with the work. Another option would be to start off the Speech API work in the Web Apps group with both proposals (the Google proposal and the SpeechXG report) and let the editors prioritize the order that the different aspects of the API are worked out and published as specs. -Original Message- From: Satish S [mailto:sat...@google.com] Sent: Thursday, January 12, 2012 5:01 PM To: Young, Milan Cc: Arthur Barstow; public-webapps; public-xg-htmlspe...@w3.org Subject: Re: to add Speech API to Charter; deadline January 19 Milan, It looks like we fundamentally agree on several things: * That we'd like to see the JavaScript Speech API included in the WebApps' charter.* That we believe the wire protocol is best suited for another organization, such as IETF.* That we believe the markup bindings may be excluded. Our only difference seems to be whether to start with the extensive Javascript API proposed in [1] or the simplified subset of it proposed in [2] which supports majority of the use cases in the XG's Final Report. Art Barstow asked for a relatively specific proposal and provided some precedence examples regarding the level of detail. [3] Olli Pettay wrote in [4] Since from practical point of view the API+protocol XG defined is a huge thing to implement at once, it makes sense to implement it in pieces. Starting with a baseline that supports the majority of use cases will accelerate implementation, interoperability testing, standardization and ultimately developer adoption. Cheers Satish [1] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/[2] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att- 1696/speechapi.html[3] http://lists.w3.org/Archives/Public/public- webapps/2011OctDec/1474.html[4] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0068.htm l On Thu, Jan 12, 2012 at 5:46 PM, Young, Milan milan.yo...@nuance.com wrote: I've made the point a few times now, and would appreciate a response. Why are we preferring to seed WebApps speech with [2] when we already have [3] that represents industry consensus as of a month ago (Google not withstanding)? Proceeding with [2] would almost surely delay the resulting specification as functionality would patched and haggled over to meet consensus. My counter proposal is to open the HTML/speech marriage in WebApps essentially where we left off at [3]. The only variants being: 1) Dropping the markup bindings in sections 7.1.2/7.1.3 because its primary supporter has since expressed non-interest, and 2) Spin the protocol specification in 7.2 out to the IETF. If I need to formalize all of this in a document, please let me know. Thank you [3] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/ -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Thursday, January 12, 2012 4:31 AM To: public-webapps Cc: public-xg-htmlspe...@w3.org Subject: CfC: to add Speech API to Charter; deadline January 19 Glen Shires and some others at Google proposed [1] that WebApps add Speech API to WebApps' charter and they put forward the Speech Javascript API Specification [2] as as a starting point. Members of Mozilla and Nuance have voiced various levels of support for this proposal. As such, this is a Call for Consensus to add Speech API to WebApps' charter. Positive response to this CfC is
Re: Selection of a document that doesn't have a window
On 1/13/12 2:37 AM, Simon Pieters wrote: HTML uses this concept in lots of places, e.g. http://www.whatwg.org/specs/web-apps/current-work/#cookie-free-document-object A Document that has no browsing context. Ah, that's better than using defaultView (because behavior for defaultView on navigation and such is not defined in the spec and is not consistent across browsers). -Boris
RE: to add Speech API to Charter; deadline January 19
I agree that getting good enough out there sooner is an excellent goal, although in practice there's always a lot of room for disagreement about what's good enough. There isn't a draft priority list now, although the XG final report does include prioritized requirements [1]. However, the requirements in the list are just prioritized into very general classes, like strong interest, so they only provide a general guide to possible priorities for the standardization work. [1] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech-20111206/#priorit ized -Original Message- From: Dave Bernard [mailto:dbern...@intellectiongroup.com] Sent: Friday, January 13, 2012 11:14 AM To: 'Deborah Dahl'; 'Satish S'; 'Young, Milan' Cc: 'Arthur Barstow'; 'public-webapps'; public-xg-htmlspe...@w3.org Subject: RE: to add Speech API to Charter; deadline January 19 Deborah- Is there a draft priority list in existence? I like the idea of getting good enough out there sooner, especially as an implementer with real projects in the space. Dave -Original Message- From: Deborah Dahl [mailto:d...@conversational-technologies.com] Sent: Friday, January 13, 2012 10:43 AM To: 'Satish S'; 'Young, Milan' Cc: 'Arthur Barstow'; 'public-webapps'; public-xg-htmlspe...@w3.org Subject: RE: to add Speech API to Charter; deadline January 19 Olli has a good point that it makes sense to implement the SpeechAPI in pieces. That doesn't mean that the WebApps WG only has to look at one proposal in deciding how to proceed with the work. Another option would be to start off the Speech API work in the Web Apps group with both proposals (the Google proposal and the SpeechXG report) and let the editors prioritize the order that the different aspects of the API are worked out and published as specs. -Original Message- From: Satish S [mailto:sat...@google.com] Sent: Thursday, January 12, 2012 5:01 PM To: Young, Milan Cc: Arthur Barstow; public-webapps; public-xg-htmlspe...@w3.org Subject: Re: to add Speech API to Charter; deadline January 19 Milan, It looks like we fundamentally agree on several things: * That we'd like to see the JavaScript Speech API included in the WebApps' charter.* That we believe the wire protocol is best suited for another organization, such as IETF.* That we believe the markup bindings may be excluded. Our only difference seems to be whether to start with the extensive Javascript API proposed in [1] or the simplified subset of it proposed in [2] which supports majority of the use cases in the XGs Final Report. Art Barstow asked for a relatively specific proposal and provided some precedence examples regarding the level of detail. [3] Olli Pettay wrote in [4] Since from practical point of view the API+protocol XG defined is a huge thing to implement at once, it makes sense to implement it in pieces. Starting with a baseline that supports the majority of use cases will accelerate implementation, interoperability testing, standardization and ultimately developer adoption. Cheers Satish [1] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/[2] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att- 1696/speechapi.html[3] http://lists.w3.org/Archives/Public/public- webapps/2011OctDec/1474.html[4] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0068.htm l On Thu, Jan 12, 2012 at 5:46 PM, Young, Milan milan.yo...@nuance.com wrote: I've made the point a few times now, and would appreciate a response. Why are we preferring to seed WebApps speech with [2] when we already have [3] that represents industry consensus as of a month ago (Google not withstanding)? Proceeding with [2] would almost surely delay the resulting specification as functionality would patched and haggled over to meet consensus. My counter proposal is to open the HTML/speech marriage in WebApps essentially where we left off at [3]. The only variants being: 1) Dropping the markup bindings in sections 7.1.2/7.1.3 because its primary supporter has since expressed non-interest, and 2) Spin the protocol specification in 7.2 out to the IETF. If I need to formalize all of this in a document, please let me know. Thank you [3] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/ -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Thursday, January 12, 2012 4:31 AM To: public-webapps Cc: public-xg-htmlspe...@w3.org Subject: CfC: to add Speech API to Charter; deadline January 19 Glen Shires and some others at Google proposed [1] that WebApps add Speech API to WebApps' charter and they put forward the Speech Javascript API Specification [2] as as a starting point. Members of Mozilla and Nuance have voiced various levels of support for this proposal. As such, this is a Call
Re: Selection of a document that doesn't have a window
On 1/13/12 12:18 PM, Aryeh Gregor wrote: Actually, defaultView is defined to return the Document's browsing context's WindowProxy object, if it has one, and null otherwise. Hmm. I guess the spec doesn't really define what happens to the association between a document and its browsing context in the interesting cases (window close, navigation away from document, removal of an iframe from the DOM, etc). In practice, UAs are all over the map in terms of nulling out defaultView for some but not others of the above. For now I'm inclined to go with defaultView being null, just because that's at least readily testable. If defaultView isn't defined well enough, that should be fixed in the HTML spec. I would prefer a definition that doesn't involve defaultView, actually. I don't expect browsers to converge defaultView behavior any time in the near or medium future, so the testability would be illusory: tests would just depend on whether browsers implement defaultView correctly... -Boris
Re: File modification
On 1/12/12 12:53 PM, Arun Ranganathan wrote: Oh I'm glad to see this one! Is it Blob and File that can be put into IDB? How do I create a new File (with a name field) from a Blob? Charles: see the thread on making Blobs constructable -- follow http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0439.html http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0918.html Seems like the consensus was to stay away from Blob to File methods. FileEntry and [a download] being the heirs apparent. Well, the consensus was to introduce a constructor to Blob, which I'm about to do :) The File API specification should do a better job describing what happens to a File if the underlying resource changes. We use the word immutable, but I think we have to make this substantially clearer. My take on a File object that's been modified is that the file no longer exists. User agents MUST process reads on files that no longer exist at the time of read as errors A file may change on disk since the original file selection, thus resulting in an invalid read. Just to be clear, disappearing a file from FileList might is the same as item(index) returning null for the the index'th item. Maybe this should be enforced as well for any kind of modification? This isn't what Fx does today. -- A*
RE: to add Speech API to Charter; deadline January 19
How prioritization works in practice depends on how a specific Working Group decides to organize its work, but generally, the W3C is very consensus-oriented and tries to make sure that all opinions are respected. -Original Message- From: Dave Bernard [mailto:dbern...@intellectiongroup.com] Sent: Friday, January 13, 2012 1:39 PM To: 'Deborah Dahl'; 'Satish S'; 'Young, Milan' Cc: 'Arthur Barstow'; 'public-webapps'; public-xg-htmlspe...@w3.org Subject: RE: to add Speech API to Charter; deadline January 19 Deborah- So how would a good democratic prioritization work, in practice? Is that something that is rare/common in similar W3C endeavors? Dave -Original Message- From: Deborah Dahl [mailto:d...@conversational-technologies.com] Sent: Friday, January 13, 2012 12:00 PM To: dbern...@intellectiongroup.com; 'Satish S'; 'Young, Milan' Cc: 'Arthur Barstow'; 'public-webapps'; public-xg-htmlspe...@w3.org Subject: RE: to add Speech API to Charter; deadline January 19 I agree that getting good enough out there sooner is an excellent goal, although in practice there's always a lot of room for disagreement about what's good enough. There isn't a draft priority list now, although the XG final report does include prioritized requirements [1]. However, the requirements in the list are just prioritized into very general classes, like strong interest, so they only provide a general guide to possible priorities for the standardization work. [1] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech- 20111206/#priorit ized -Original Message- From: Dave Bernard [mailto:dbern...@intellectiongroup.com] Sent: Friday, January 13, 2012 11:14 AM To: 'Deborah Dahl'; 'Satish S'; 'Young, Milan' Cc: 'Arthur Barstow'; 'public-webapps'; public-xg-htmlspe...@w3.org Subject: RE: to add Speech API to Charter; deadline January 19 Deborah- Is there a draft priority list in existence? I like the idea of getting good enough out there sooner, especially as an implementer with real projects in the space. Dave -Original Message- From: Deborah Dahl [mailto:d...@conversational-technologies.com] Sent: Friday, January 13, 2012 10:43 AM To: 'Satish S'; 'Young, Milan' Cc: 'Arthur Barstow'; 'public-webapps'; public-xg-htmlspe...@w3.org Subject: RE: to add Speech API to Charter; deadline January 19 Olli has a good point that it makes sense to implement the SpeechAPI in pieces. That doesn't mean that the WebApps WG only has to look at one proposal in deciding how to proceed with the work. Another option would be to start off the Speech API work in the Web Apps group with both proposals (the Google proposal and the SpeechXG report) and let the editors prioritize the order that the different aspects of the API are worked out and published as specs. -Original Message- From: Satish S [mailto:sat...@google.com] Sent: Thursday, January 12, 2012 5:01 PM To: Young, Milan Cc: Arthur Barstow; public-webapps; public-xg-htmlspe...@w3.org Subject: Re: to add Speech API to Charter; deadline January 19 Milan, It looks like we fundamentally agree on several things: * That we'd like to see the JavaScript Speech API included in the WebApps' charter.* That we believe the wire protocol is best suited for another organization, such as IETF.* That we believe the markup bindings may be excluded. Our only difference seems to be whether to start with the extensive Javascript API proposed in [1] or the simplified subset of it proposed in [2] which supports majority of the use cases in the XGs Final Report. Art Barstow asked for a relatively specific proposal and provided some precedence examples regarding the level of detail. [3] Olli Pettay wrote in [4] Since from practical point of view the API+protocol XG defined is a huge thing to implement at once, it API+makes sense to implement it in pieces. Starting with a baseline that supports the majority of use cases will accelerate implementation, interoperability testing, standardization and ultimately developer adoption. Cheers Satish [1] http://www.w3.org/2005/Incubator/htmlspeech/XGR- htmlspeech/[2] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att- 1696/speechapi.html[3] http://lists.w3.org/Archives/Public/public- webapps/2011OctDec/1474.html[4] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0068.h tm l On Thu, Jan 12, 2012 at 5:46 PM, Young, Milan milan.yo...@nuance.com wrote: I've made the point a few times now, and would appreciate a response. Why are we preferring to seed WebApps speech with [2] when we already have [3] that represents industry consensus as of a month ago (Google not withstanding)? Proceeding with [2] would almost surely delay the resulting specification as functionality would
Re: Selection of a document that doesn't have a window
On Fri, Jan 13, 2012 at 12:34 PM, Boris Zbarsky bzbar...@mit.edu wrote: I would prefer a definition that doesn't involve defaultView, actually. I don't expect browsers to converge defaultView behavior any time in the near or medium future, so the testability would be illusory: tests would just depend on whether browsers implement defaultView correctly... What well-defined alternative do you suggest? Is the .document of some Window? That would be easy enough to test in simple cases, but what if there's navigation and a reference to the Document is kept but the Window is no longer accessible, or something like that?
Re: File modification
On 1/13/12 11:13 AM, Arun Ranganathan wrote: On 1/12/12 12:53 PM, Arun Ranganathan wrote: Oh I'm glad to see this one! Is it Blob and File that can be put into IDB? How do I create a new File (with a name field) from a Blob? Charles: see the thread on making Blobs constructable -- follow http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0439.html http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0918.html Seems like the consensus was to stay away from Blob to File methods. FileEntry and [a download] being the heirs apparent. Well, the consensus was to introduce a constructor to Blob, which I'm about to do :) Sorry, I misread that thread; and misremembered it. I saw it as appending multiple strings. I'm happy to see the Blob constructor happening! The File API specification should do a better job describing what happens to a File if the underlying resource changes. We use the word immutable, but I think we have to make this substantially clearer. My take on a File object that's been modified is that the file no longer exists. User agents MUST process reads on files that no longer exist at the time of read as errors A file may change on disk since the original file selection, thus resulting in an invalid read. Just to be clear, disappearing a file from FileList might is the same as| item(index) |returning null for the the index'th item. Maybe this should be enforced as well for any kind of modification? This isn't what Fx does today. I'm fine with that being the defined behavior for FileList when implementations have elected to remove modified files. It's still optional: implementations MAY remove modified files from the FileList, those that do MUST return null for the index'th item. I'm hoping they don't go down that route. It may mean a disconnect between the results of submitting a post and the files available to the scripting environment. Again, I don't imagine that input type=file and a subsequent .submit() would result in an empty POST when the user modifies the underlying file. Though it should do so if the user deletes or renames the underlying file. I suppose things could get nasty, though, if the user modifies the file while the post is happening. I don't want to think about those kind of race conditions. Hopefully the UA can put a temporary write lock on those files. Well... I'm satisfied on this topic. I think we've incrementally improved what the File API will specify. -Charles
Re: File modification
That would be bad; it would require null checks that people would forget to perform due to the rarity of the condition. Instead, it should return a File that fails when read attempts are made. (Of course, those errors are also rare, but it's at least not adding a *new* rare case.) On Jan 13, 2012 12:13 PM, Arun Ranganathan aranganat...@mozilla.com wrote: On 1/12/12 12:53 PM, Arun Ranganathan wrote: Oh I'm glad to see this one! Is it Blob and File that can be put into IDB? How do I create a new File (with a name field) from a Blob? Charles: see the thread on making Blobs constructable -- follow http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0439.html http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0918.html Seems like the consensus was to stay away from Blob to File methods. FileEntry and [a download] being the heirs apparent. Well, the consensus was to introduce a constructor to Blob, which I'm about to do :) The File API specification should do a better job describing what happens to a File if the underlying resource changes. We use the word immutable, but I think we have to make this substantially clearer. My take on a File object that's been modified is that the file no longer exists. User agents MUST process reads on files that no longer exist at the time of read as errors A file may change on disk since the original file selection, thus resulting in an invalid read. Just to be clear, disappearing a file from FileList might is the same as item(index) returning null for the the index'th item. Maybe this should be enforced as well for any kind of modification? This isn't what Fx does today. -- A*
Re: Use Cases for Connectionless Push support in Webapps recharter
On Fri, 13 Jan 2012, Arthur Barstow wrote: Hixie - what are your thoughts on these UCs and how they would be spec'ed? For example, would they be in a different spec, an L.next type spec? Well there's two parts to it: the protocol, and the API. If there's an existing protocol for this and the browser vendors are interested in implementing it, I see no reason why we couldn't support this alongside the current text/event-stream-based API in the HTML standard, either as part of the same API or as a separate API (like WebSockets). If it needs a new protocol, then that should probably be addressed first. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[Bug 15554] New: Hi, The article is very good. Also user can view. HTML5 Web Workers http://www.totaldotnet.com/Article/ShowArticle145_HTML5WebWorker.aspx
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15554 Summary: Hi, The article is very good. Also user can view. HTML5 Web Workers http://www.totaldotnet.com/Article/ShowArticle145_HTML 5WebWorker.aspx Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Web Workers (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Specification: http://dev.w3.org/html5/workers/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: Hi, The article is very good. Also user can view. HTML5 Web Workers http://www.totaldotnet.com/Article/ShowArticle145_HTML5WebWorker.aspx Posted from: 1.23.229.131 User agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0) -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
