RE: [push-api] Moving Push API to FPWD [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15]
On 27 sep 2012 at 05:51:51, SULLIVAN, BRYAN L wrote: Thanks for the feedback, Art. I've responded below. I will work on a new draft to address as many of your comments as I can. Thanks, Bryan Sullivan | Service Standards | ATT +1-425-580-6514 Arthur Barstow wrote on September 26, 2012 11:59 AM: specs before TPAC: CfC start deadline is Oct 15] On 9/26/12 1:49 PM, ext SULLIVAN, BRYAN L wrote: We've previously called for any comments to the current Push API draft [1], and would like to promote it to FPWD before TPAC. We haven't received any substantive comments as far as I know, which tells me that it could be in good shape for publication. With the addition of Telefonica (Eduardo) as co-editor and simplification / better alignment with proposals for B2G / Firefox OS, I believe we are in shape for FPWD now. So if I could request a CFC for publication as FPWD before Oct 15, that would be our preference. Alternatively we can put this on the agenda for TPAC and discuss/promote it then as possible. But in the absence of substantive comments (which tells me we have addressed most of the comments on the first ED), I think we should be ready for FPWD. [1] http://dvcs.w3.org/hg/push/raw-file/default/index.html The requirements for FPWD are relatively loose but because the publication of a FPWD starts a Call for (IP) Exclusions, it is helpful for some reviewers if the breath of the spec is mostly complete, although the depth can certainly be lacking. What is your view on the set of features/scope? Is the ED covering most of the scope? If there are any high priority features missing, what are they? IMO the ED is covering the scope well. I don't think any high priority features are missing. We removed some of the earlier proposed features in the current draft. I agree we are covering most of the scope. It is a matter of adding more depth. Based on a very quick scan, I noticed: * The Privacy and Security section is empty and I think it would be helpful if some additional informational was added before FPWD. I have some text I can add for that. * The Specific Service Bindings section is empty. It seems like this should have some information before FPWD, especially if it is going to be a normative section. (Are some of these bindings specified outside the W3C?) I think this was intended to be an informative section, unless at least one push service is proposed to be standardized. I can provide informative text for SMS, SIP, and OMA Push. Browser-specific push serices could also be included. * Push Framework - it appears this section should be marked as non-normative. I think it would be helpful if some type of flow diagram was included as well as example application code to use the API (although this non-normative info is not necessarily a blocker for FPWD). Agreed, this should be informative. Yes, it is intended to be an informative section. Flow diagram would definitely be useful, though not necessary to go to FPWD * serverProtocols - what are the expectations for the valid set of values; where are they specified? Good question. We need some means of registration of well-known services so the protocols can be recognized. Some editorial comments ... * Define Web Intent Push Service provider, Push server and webapp or add a link to the definitions. Will do. * Update the references that are out of date (e.g. HTML5). Will do. This is respec.js magic. * Not clear what onopen event is since it isn't part of the PushService API I think this may have been an omission, or we were thinking to use a listener for changes to the readyState as the open event. I will check with Eduardo on that. I think for the time being we can remove onopen as there is no other reference to it in the draft. -Thanks, Art Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx
Re: [XHR] chunked
On Thu, Jun 7, 2012 at 11:48 AM, Wenbo Zhu wen...@google.com wrote: On Thu, Jun 7, 2012 at 2:34 AM, Anne van Kesteren ann...@annevk.nl wrote: Can I take this as Chrome being interested in implementing the chunked proposal as well? Will have to get back to you on this, since I am mostly working on servers and HTTP/application protocols. Still trying to figure out what to do here. Any other XMLHttpRequest implementors hoping to implement this feature? Has it been adopted by developers? -- http://annevankesteren.nl/
Re: [IndexedDB] blocked event could be an error
http://odinho.html5.org/IndexedDB/spec/Overview.html Like I said, I think it's too late to make such a big change. I believe it's much too late to make such a change in IE10, and we have been shipping Firefox with the current behavior for quite a while now (and are about to unprefix with our current behavior). / Jonas Sorry but it is not late. It's actually quite early and the right time. The spec is still a working draft, all uses so far of IDB online are either html5 benchmarks or tutorials/examples. So, nothing of importance will be affected, Besides, this is a corner case.
Re: [XHR] chunked
On Thu, Sep 27, 2012 at 6:27 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Jun 7, 2012 at 11:48 AM, Wenbo Zhu wen...@google.com wrote: On Thu, Jun 7, 2012 at 2:34 AM, Anne van Kesteren ann...@annevk.nl wrote: Can I take this as Chrome being interested in implementing the chunked proposal as well? Will have to get back to you on this, since I am mostly working on servers and HTTP/application protocols. Still trying to figure out what to do here. Any other XMLHttpRequest implementors hoping to implement this feature? Has it been adopted by developers? I know pdf.js uses this in order to implement incremental rendering of pdf files. I do somewhat agree that if we had a full stream solution in the form of a Stream primitive and .responseType=stream, then a better solution might be to use that in combination with having chunked delivery on the Stream class instead. / Jonas
Re: [XHR] chunked
On Thu, Sep 27, 2012 at 6:23 PM, Jonas Sicking jo...@sicking.cc wrote: I do somewhat agree that if we had a full stream solution in the form of a Stream primitive and .responseType=stream, then a better solution might be to use that in combination with having chunked delivery on the Stream class instead. Was Microsoft going to take a stab at that? I could write something like that up in XMLHttpRequest I suppose. Although maybe that would require a bunch of coordination with the MediaStream stuff? -- http://annevankesteren.nl/
Re: [IndexedDB] blocked event could be an error
On Thu, Sep 27, 2012 at 6:47 AM, João Eiras jo...@opera.com wrote: http://odinho.html5.org/IndexedDB/spec/Overview.html Like I said, I think it's too late to make such a big change. I believe it's much too late to make such a change in IE10, and we have been shipping Firefox with the current behavior for quite a while now (and are about to unprefix with our current behavior). / Jonas Sorry but it is not late. It's actually quite early and the right time. I don't know by what measure it's quite early or the right time. We've passed Last Call, there are 3 shipping implementations, all of which have considered their implementation complete enough to switch from prefixed implementations to unprefixed ones. They all implement the behavior that you are proposing to change. At least the Amazon cloud reader uses IndexedDB. I've started receiving enough questions about IDB that I would imagine that there are more websites deployed which uses it. / Jonas
Re: [XHR] chunked
On Thu, Sep 27, 2012 at 9:26 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Sep 27, 2012 at 6:23 PM, Jonas Sicking jo...@sicking.cc wrote: I do somewhat agree that if we had a full stream solution in the form of a Stream primitive and .responseType=stream, then a better solution might be to use that in combination with having chunked delivery on the Stream class instead. Was Microsoft going to take a stab at that? I could write something like that up in XMLHttpRequest I suppose. Although maybe that would require a bunch of coordination with the MediaStream stuff? I can't speak to anyone else's plans. But it does seem like a proposal was made quite a long time ago and as I recall it it received favorable feedback, but so far nothing else has happened. / Jonas
RE: [XHR] chunked
From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On On Thu, Sep 27, 2012 at 7:00 PM, Travis Leithead travis.leith...@microsoft.com wrote: It hasn't been updated in a while, but we're still keen on seeing it move forward AFAIK: http://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm Cool. I can integrate the relevant bits into XMLHttpRequest. Do I understand it correctly that it does not allow for streaming data towards the server? It seems to just copy the data from the Stream object that it currently represents and that's that. Is that really what we want here? In my observation of the current IE behavior, the Stream is for download only. XHR gets the data from the server and buffers it. The consumer of the stream then pulls data as needed which is extracted from the buffer.
Re: [XHR] chunked
On Thu, Sep 27, 2012 at 7:42 PM, Travis Leithead travis.leith...@microsoft.com wrote: In my observation of the current IE behavior, the Stream is for download only. XHR gets the data from the server and buffers it. The consumer of the stream then pulls data as needed which is extracted from the buffer. I see, so the bit where it says you can pass it to send() we should maybe not add for now if it's not going to do something useful. -- http://annevankesteren.nl/
[admin] Call for Editor for DOM4 REC track spec
Hi All, The current Editors of the DOM4 spec are not interested in moving that spec toward Recommendation (in the context of WebApps WG). Consequently, we need an Editor(s) to work on the DOM4 Recommendation track document. If you are interested in this Editor position and have relevant experience, please contact me offlist. -Thanks, ArtB [DOM4] http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html
RE: [XHR] chunked
From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Thu, Sep 27, 2012 at 7:42 PM, Travis Leithead travis.leith...@microsoft.com wrote: In my observation of the current IE behavior, the Stream is for download only. XHR gets the data from the server and buffers it. The consumer of the stream then pulls data as needed which is extracted from the buffer. I see, so the bit where it says you can pass it to send() we should maybe not add for now if it's not going to do something useful. I honestly haven't tested that part, but this seems safe (it can be added- in later if need be).
[widgets] Packaged Web Apps (Widgets) - Packaging and XML Configuration (Second Edition) is a Proposed Edited Recommendation
Earlier today the W3C announced: [[ ... the advancement of Packaged Web Apps (Widgets) - Packaging and XML Configuration (Second Edition) to Proposed Edited Recommendation http://www.w3.org/TR/2012/PER-widgets-20120925/ This second edition incorporates all known errata as of the publication date. The main change is the folding or 'white space' and 'Unicode white space' as only 'white space'. The document still reference the Unicode specification as the authoritative source of white space definition, all the white space references in the previous specification were including a reference to Unicode white space. No conformance issues are foreseen with this change. This edition, once it becomes a Recommendation, will supersede the previous edition of 27 September 2011. ]] W3C Advisory Committee members are asked to Please review the specification and indicate whether you endorse it as W3C Recommendation or object to its advancement by completing the following questionnaire https://www.w3.org/2002/09/wbs/33280/widget2e/. -AB
Re: [widgets] Packaged Web Apps (Widgets) - Packaging and XML Configuration (Second Edition) is a Proposed Edited Recommendation
On 9/27/12 9:35 PM, Arthur Barstow art.bars...@nokia.com wrote: W3C Advisory Committee members are asked to Please review the specification and indicate whether you endorse it as W3C Recommendation or object to its advancement by completing the following questionnaire https://www.w3.org/2002/09/wbs/33280/widget2e/. I'm getting the following error when answering the questionnaire: Saving failed with error Program error: a widget must be loaded before creation Saving failed with error Program error: a widget must be loaded before creation Saving failed with error Program error: a widget must be loaded before creation Saving failed with error Program error: a widget must be loaded before creation Saving failed with error Program error: a widget must be loaded before creation Saving failed with error Program error: a widget must be loaded before creation --tobie
Re: [XHR] chunked
On Thu, Sep 27, 2012 at 12:21 PM, Travis Leithead travis.leith...@microsoft.com wrote: From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Thu, Sep 27, 2012 at 7:42 PM, Travis Leithead travis.leith...@microsoft.com wrote: In my observation of the current IE behavior, the Stream is for download only. XHR gets the data from the server and buffers it. The consumer of the stream then pulls data as needed which is extracted from the buffer. I see, so the bit where it says you can pass it to send() we should maybe not add for now if it's not going to do something useful. I honestly haven't tested that part, but this seems safe (it can be added- in later if need be). The send() version, i.e. chunked requests, will actually be more useful, but I guess someone has to use it first, e.g. to cut the number of requests.
Re: [admin] Call for Editor for DOM4 REC track spec
It is worth noting that this is a critical path blocker for publishing HTML5 as a REC. On Fri, Sep 28, 2012 at 2:59 AM, Arthur Barstow art.bars...@nokia.comwrote: Hi All, The current Editors of the DOM4 spec are not interested in moving that spec toward Recommendation (in the context of WebApps WG). Consequently, we need an Editor(s) to work on the DOM4 Recommendation track document. If you are interested in this Editor position and have relevant experience, please contact me offlist. -Thanks, ArtB [DOM4] http://dvcs.w3.org/hg/**domcore/raw-file/tip/Overview.**htmlhttp://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html
[Bug 18749] Why removing exception throwing from binaryType
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18749 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|REOPENED|RESOLVED CC||i...@hixie.ch Resolution||WONTFIX --- Comment #5 from Ian 'Hixie' Hickson i...@hixie.ch 2012-09-28 03:23:02 UTC --- Yeah, the plan here is to be consistent with other things in the platform. -- 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.
