RE: Defining generic Stream than considering only bytes (Re: CfC: publish WD of Streams API; deadline Nov 3)
A few comments inline below - From: tyosh...@google.com Date: Thu, 31 Oct 2013 13:23:26 +0900 To: d...@deanlandolt.com CC: art.bars...@nokia.com; public-webapps@w3.org Subject: Defining generic Stream than considering only bytes (Re: CfC: publish WD of Streams API; deadline Nov 3) Hi Dean, On Thu, Oct 31, 2013 at 11:30 AM, Dean Landolt d...@deanlandolt.commailto:d...@deanlandolt.com wrote: I really like this general concepts of this proposal, but I'm confused by what seems like an unnecessary limiting assumption: why assume all streams are byte streams? This is a mistake node recently made in its streams refactor that has led to an objectMode and added cruft. Forgive me if this has been discussed -- I just learned of this today. But as someone who's been slinging streams in javascript for years I'd really hate to see the standard stream hampered by this bytes-only limitation. The node ecosystem clearly demonstrates that streams are for more than bytes and (byte-encoded) strings. To glue Streams with existing binary handling infrastructure such as ArrayBuffer, Blob, we should have some specialization for Stream handling bytes rather than using generalized Stream that would accept/output an array or single object of the type. Maybe we can rename Streams API to ByteStream not to occupy the name Stream that sounds like more generic, and start standardizing generic Stream. Dean, it sounds like your concern isnt just around the naming, but rather how data is read out of a stream. I've reviewed both the Node Streams and Buffer APIs previously, and from my understanding the data is provided as either a Buffer or String. This is on-par with ArrayBuffer/String. What data do you want to obtain that is missing, and for what scenario? Are these data types that already exist in the web platform, or new types you think are missing? In my perfect world any arbitrary iterator could be used to characterize stream chunks -- this would have some really interesting benefits -- but I suspect this kind of flexibility would be overkill for now. But there's good no reason bytes should be the only thing people can chunk up in streams. And if we're defining streams for the whole platform they shouldn't just be tied to a few very specific file-like use cases. If streams could also consist of chunks of strings (real, native strings) a huge swath of the API could disappear. All of readType, readEncoding and charset could be eliminated, replaced with simple, composable transforms that turn byte streams (of, say, utf-8) into string streams. And vice versa. So, for example, XHR would be the point of decoding and it returns a Stream of DOMStrings? Of course the real draw of this approach would be when chunks are neither blobs nor strings. Why couldn't chunks be arrays? The arrays could contain anything (no need to reserve any value as a sigil). Regardless of the chunk type, the zero object for any given type wouldn't be `null` (it would be something like '' or []). That means we can use null to distinguish EOF, and `chunk == null` would make a perfectly nice (and unambiguous) EOF sigil, eliminating yet more API surface. This would give us a clean object mode streams for free, and without node's arbitrary limitations. For several reasons, I chose to use .eof than using null. One of them is to allow the non-empty final chunk to signal EOF than requiring one more read() call. This point can be re-discussed. I thought EOF made sense here as well, but it's something that can be changed. Your proposal is interesting - is something like this currently implemented anywhere? This behavior feels like it'd require several changes elsewhere, since some APIs and libraries may explicitly look for an EOF. The `size` of an array stream would be the total length of all array chunks. As I hinted before, we could also leave the door open to specifying chunks as any iterable, where `size` (if known) would just be the `length` of each chunk (assuming chunks even have a `length`). This would also allow individual chunks to be built of generators, which could be particularly interesting if the `size` argument to `read` was specified as a maximum number of bytes rather than the total to return -- completely sensible considering it has to behave this way near the end of the stream anyway... I don't really understand the last point. Could you please elaborate the story and benefit? IIRC, it's considered to be useful and important to be able to cut an exact requested size of data into an ArrayBuffer object and get notified (the returned Promise gets resolved) only when it's ready. This would lead to a pattern like `stream.read(Infinity)`, which would essentially say give me everything you've got soon as you can. In current proposal, read() i.e. read() with
Re: Splitting Stream into InputStream and OutputStream (was Re: CfC: publish WD of Streams API; deadline Nov 3)
Yes, having the InputStream and OutputStream interfaces would be great, and the
“Stream” class could inherit from both. The important thing is that an external
API can return either a readable or a writable stream, depending on what make
sense for it.
Since JavaScript does not provide a way to check if an object implements an
interface, there should probably exist a way to check that from the API, like:
var stream = InputStream(s) // returns “s” if it’s an input stream, convert
is into a stream if possible, or return null
if(stream) { … } else { … }
That’s a great way to convert a string into a stream, for example, in the case
of an API that requires an InputStream and must integrate with older code that
returns a String or a Blob.
De : Takeshi Yoshino
Envoyé : jeudi 31 octobre 2013 04:45
À : François REMY
Cc : Arthur Barstow, public-webapps@w3.org
Hi François
On Thu, Oct 31, 2013 at 6:16 AM, François REMY francois.remy@outlook.com
wrote:
- Streams should exist in at least two fashions: InputStream and OutputStream.
Both of them serve different purposes and, while some stream may actually be
both, this remains an exceptional behavior worth being noted. Finally, a
Stream is not equal to a InMemoryStream as the constructor may seem to
indicate. A stream is a much lower-level concept, which may actually have
nothing to do with InMemory operations.
Yes. I initially thought it'll be clearer to split in/out interface. E.g. a
Stream obtained from XHR to receive a response should not be writable. It's
reasonable to make network-to-Stream transfer happen in background
asynchronously to JavaScript, and then it doesn't make much sense to keep it
writable from JavaScript.
It has a unified IDL now but I'm designing write side and read side
independently. We could decouple it into two separate IDLs? concepts? if it
make sense. Stream would inherit from both and provides a constructor.
Re: publish WD of Streams API; deadline Nov 3
On Wed, Oct 30, 2013 at 6:04 PM, Domenic Denicola dome...@domenicdenicola.com wrote: I have concrete suggestions as to what such an API could look like—and, more importantly, how its semantics would significantly differ from this one—which I hope to flesh out and share more broadly by the end of this weekend. However, since the call for comments phase has commenced, I thought it important to voice these objections as soon as possible. Given how long we have been trying to figure out streams, waiting a little longer to see Domenic's proposal should be fine I think. No need to start rushing things through the process now. (Although on the flipside at some point we will need to start shipping something.) -- http://annevankesteren.nl/
[coord] Is there still a need for WebApps + SysApps meeting at TPAC?
[ My apologies in advance for cross-posting but I think it's needed for this coordination topic. ] Hi All, Last June, the Chairs of WebApps and SysApps agreed to allocate a time slot @ TPAC Shenzhen for a joint meeting from 16:00-17:00 on Monday November 11 [1]. The one topic currently identified for that slot is the Manifest spec. Marcos - would you please summarize the overall `state` of the Manifest spec (f.ex. the status, next steps, blockers, and such)? I would also like to know if you think there are some related issues that could potentially benefit from some meeting time, or if we can use the list server instead. All - are there any other topics to discuss? (I'm trying to get a sense if this meeting should be canceled or perhaps reduced to 30 mins.) -Thanks, AB [1] http://www.w3.org/wiki/Webapps/November2013Meeting#Agenda_Monday_November_11
Re: [FileAPI]
Hi, For the purposes of tracking your comments for the September 12 File API Last Call Working Draft, please let us know if Arun's reply is satisfactory or not. In the absence of a reply from you by November 7, we will assume Arun's reply is OK with you. -Thanks, ArtB On 10/23/13 6:04 PM, ext Arun Ranganathan wrote: Hi there! On Oct 23, 2013, at 12:32 PM, psweatte wrote: 7.2 Interface File: -add creationDate property Thanks for your feedback. *Most* filesystems don't really have a creation time. While Windows does, Unix-style OS return the *change time or last modified time. Since we want fidelity with OS filesystems wherever possible, I'm not sure this is a viable property to add. -add size property This already exists via the inheritance relationship with Blob. -If the last modification date and time are not known, the attribute must return an empty string Currently the spec says to return the current date and time. It's a Date not a String. 8.3. Event Handler Attributes I think the current set of event handler attributes is sufficient, especially given the backdrop of event models in general not being the best way to asynchronously access large data sets such as File and Blob. -add onNotfounderror event handler -add onReaderror event handler -add onSecurityerror event handler -add onHTTPerror event handler -add onSelectfrombrowse event handler
Re: [coord] Is there still a need for WebApps + SysApps meeting at TPAC?
On Thursday, October 31, 2013 at 12:51 PM, Arthur Barstow wrote: [ My apologies in advance for cross-posting but I think it's needed for this coordination topic. ] Hi All, Last June, the Chairs of WebApps and SysApps agreed to allocate a time slot @ TPAC Shenzhen for a joint meeting from 16:00-17:00 on Monday November 11 [1]. The one topic currently identified for that slot is the Manifest spec. Marcos - would you please summarize the overall `state` of the Manifest spec (f.ex. the status, next steps, blockers, and such)? I would also like to know if you think there are some related issues that could potentially benefit from some meeting time, or if we can use the list server instead. I’m trying to figure out (or get agreement amongst those interested in implementing) if we should have a JSON manifest or go with the meta tag solution (or both) - this is a blocker. Current steps are for me to investigate the solutions and usage on teh Webs. No significant work has been done on the spec since it moved over to WebApps. I don’t mind if we do it on the list. But if others want me to dial in to discuss, I’m ok to do that. All - are there any other topics to discuss? Not from me. -- Marcos Caceres
RE: [coord] Is there still a need for WebApps + SysApps meeting at TPAC?
I want to say that we are interested in implementing the JSON manifest and also to discuss additions to the manifest. Content security policies have already been mentioned and we are looking at something similar to http://developer.chrome.com/extensions/contentSecurityPolicy.html, which allows inclusion of content security policies to support secure hosted apps by defining schemes (https:) that are allowed to use for whitelisting secure origins from which scripts should be accepted. I would also like to better understand what a meta tag solution would mean. However, as the manifest specification editor Marcos unfortunately is not able to participate in TPAC I am not sure on the most efficient way to discuss the manifest, a joint SysApps-WebApps session with Marcos calling in or a mailing list discussion. My main point is to stress our interest in the manifest specification and additions to it. BR Claes -Original Message- From: Marcos Caceres [mailto:w...@marcosc.com] Sent: den 31 oktober 2013 15:20 To: Arthur Barstow Cc: public-webapps; public-sysa...@w3.org Subject: Re: [coord] Is there still a need for WebApps + SysApps meeting at TPAC? On Thursday, October 31, 2013 at 12:51 PM, Arthur Barstow wrote: [ My apologies in advance for cross-posting but I think it's needed for this coordination topic. ] Hi All, Last June, the Chairs of WebApps and SysApps agreed to allocate a time slot @ TPAC Shenzhen for a joint meeting from 16:00-17:00 on Monday November 11 [1]. The one topic currently identified for that slot is the Manifest spec. Marcos - would you please summarize the overall `state` of the Manifest spec (f.ex. the status, next steps, blockers, and such)? I would also like to know if you think there are some related issues that could potentially benefit from some meeting time, or if we can use the list server instead. I’m trying to figure out (or get agreement amongst those interested in implementing) if we should have a JSON manifest or go with the meta tag solution (or both) - this is a blocker. Current steps are for me to investigate the solutions and usage on teh Webs. No significant work has been done on the spec since it moved over to WebApps. I don’t mind if we do it on the list. But if others want me to dial in to discuss, I’m ok to do that. All - are there any other topics to discuss? Not from me. -- Marcos Caceres
Re: [coord] Is there still a need for WebApps + SysApps meeting at TPAC?
On 2013-10-31 16:04, Nilsson, Claes1 wrote: I want to say that we are interested in implementing the JSON manifest and also to discuss additions to the manifest. Content security policies have already been mentioned and we are looking at something similar to http://developer.chrome.com/extensions/contentSecurityPolicy.html, which allows inclusion of content security policies to support secure hosted apps by defining schemes (https:) that are allowed to use for whitelisting secure origins from which scripts should be accepted. http://developer.chrome.com/extensions/manifest.html The definition of the signature seems to be missing here. If JSON still is the choice, JWS (http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-17) or JCS (https://openkeystore.googlecode.com/svn/resources/trunk/docs/JSON-Clear-Text-Signature-Scheme.pdf) are the two hottest candidates. Cheers Anders I would also like to better understand what a meta tag solution would mean. However, as the manifest specification editor Marcos unfortunately is not able to participate in TPAC I am not sure on the most efficient way to discuss the manifest, a joint SysApps-WebApps session with Marcos calling in or a mailing list discussion. My main point is to stress our interest in the manifest specification and additions to it. BR Claes -Original Message- From: Marcos Caceres [mailto:w...@marcosc.com] Sent: den 31 oktober 2013 15:20 To: Arthur Barstow Cc: public-webapps; public-sysa...@w3.org Subject: Re: [coord] Is there still a need for WebApps + SysApps meeting at TPAC? On Thursday, October 31, 2013 at 12:51 PM, Arthur Barstow wrote: [ My apologies in advance for cross-posting but I think it's needed for this coordination topic. ] Hi All, Last June, the Chairs of WebApps and SysApps agreed to allocate a time slot @ TPAC Shenzhen for a joint meeting from 16:00-17:00 on Monday November 11 [1]. The one topic currently identified for that slot is the Manifest spec. Marcos - would you please summarize the overall `state` of the Manifest spec (f.ex. the status, next steps, blockers, and such)? I would also like to know if you think there are some related issues that could potentially benefit from some meeting time, or if we can use the list server instead. I’m trying to figure out (or get agreement amongst those interested in implementing) if we should have a JSON manifest or go with the meta tag solution (or both) - this is a blocker. Current steps are for me to investigate the solutions and usage on teh Webs. No significant work has been done on the spec since it moved over to WebApps. I don’t mind if we do it on the list. But if others want me to dial in to discuss, I’m ok to do that. All - are there any other topics to discuss? Not from me. -- Marcos Caceres
Re: [coord] Is there still a need for WebApps + SysApps meeting at TPAC?
On Thursday, October 31, 2013 at 3:04 PM, Nilsson, Claes1 wrote: I want to say that we are interested in implementing the JSON manifest and also to discuss additions to the manifest. Content security policies have already been mentioned and we are looking at something similar to http://developer.chrome.com/extensions/contentSecurityPolicy.html, which allows inclusion of content security policies to support secure hosted apps by defining schemes (https:) that are allowed to use for whitelisting secure origins from which scripts should be accepted. This is orthogonal to the manifest, as web apps can already do this. Adding this to the manifest would only be sugar to allow developers to tighten the CSP. I would also like to better understand what a meta tag solution would mean. See: https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/MetaTags.html And: https://developers.google.com/chrome/mobile/docs/installtohomescreen So, some standardized thing of the above (without the proprietary prefixes, of course). However, as the manifest specification editor Marcos unfortunately is not able to participate in TPAC I am not sure on the most efficient way to discuss the manifest, a joint SysApps-WebApps session with Marcos calling in or a mailing list discussion. I’m happy to dial in, but would like to know specially what people want to discuss about it. My main point is to stress our interest in the manifest specification and additions to it. I think it’s more important to understand the use cases, and then we can evaluate if the manifest is the appropriate place to address those.
Re: [FileAPI]
Note that all LC Commentary, including that sent on this listserv, is tracked here: http://www.w3.org/wiki/Webapps/LCWD-FileAPI-20130912 -- A* On Oct 31, 2013, at 9:12 AM, Arthur Barstow wrote: Hi, For the purposes of tracking your comments for the September 12 File API Last Call Working Draft, please let us know if Arun's reply is satisfactory or not. In the absence of a reply from you by November 7, we will assume Arun's reply is OK with you. -Thanks, ArtB On 10/23/13 6:04 PM, ext Arun Ranganathan wrote: Hi there! On Oct 23, 2013, at 12:32 PM, psweatte wrote: 7.2 Interface File: -add creationDate property Thanks for your feedback. *Most* filesystems don't really have a creation time. While Windows does, Unix-style OS return the *change time or last modified time. Since we want fidelity with OS filesystems wherever possible, I'm not sure this is a viable property to add. -add size property This already exists via the inheritance relationship with Blob. -If the last modification date and time are not known, the attribute must return an empty string Currently the spec says to return the current date and time. It's a Date not a String. 8.3. Event Handler Attributes I think the current set of event handler attributes is sufficient, especially given the backdrop of event models in general not being the best way to asynchronously access large data sets such as File and Blob. -add onNotfounderror event handler -add onReaderror event handler -add onSecurityerror event handler -add onHTTPerror event handler -add onSelectfrombrowse event handler
[Bug 23319] 第6.4.1.节,多了个右括号
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23319 Arun a...@mozilla.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Arun a...@mozilla.com --- Fixed this in editor's draft. http://dev.w3.org/2006/webapi/FileAPI/#slice-method-algo -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 23451] Error Attribute Setting and Error Event Firing Currently Have Backwards Order
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23451 Arun a...@mozilla.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Arun a...@mozilla.com --- Fixed. http://dev.w3.org/2006/webapi/FileAPI/#dfn-error-steps -- You are receiving this mail because: You are on the CC list for the bug.
RfC: LCWD of Pointer Lock; deadline November 28
This is a Request for Comments for the Last Call Working Draft of Pointer Lock: http://www.w3.org/TR/2013/WD-pointerlock-20131031/ If you have any comments, please send them to public-webapps @ w3.org by November 28 using a Subject: header of [pointerlock]. -Thanks, AB
[widgets] Widget Interface is a W3C Recommendation
A Recommendation of Widget Interface was published today: http://www.w3.org/TR/2013/REC-widgets-apis-20131031/ Congratulations Marcos! This publication means that of WebApps' 7 widget related documents, 5 are now Recommendations and the other 2 are WG Notes. As such, the group's widget spec work is `completed`. I added the following to the group's `Charter Updates` wiki as a reminder that if/when WebApps' charter is updated, we have a decision point re widgets: [[ http://www.w3.org/wiki/Webapps/Charter#Potential_Deletions * Widgets - WebApps published 5 widget-related Recommendations ^1. When the group next updates the charter, should the widget specs all be removed? What about their maintenance? ]] -AB ^1 http://www.w3.org/2008/webapps/wiki/PubStatus#Widget_Specifications
[Bug 23431] File API should say what to do with the query string in blob: URLs
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23431 Arun a...@mozilla.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Arun a...@mozilla.com --- Fixed. http://dev.w3.org/2006/webapi/FileAPI/#queryString -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 23416] Introduce new concept of neutered
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23416 Arun a...@mozilla.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Arun a...@mozilla.com --- (In reply to Ian 'Hixie' Hickson from comment #11) The concept of neutered in the Transferable sense is this can't be transferred any more. Anything that isn't Transferable is always in that state, so it doesn't make sense to talk about other things being neutered in the Transferable sense. If File and Blob should be Transferable (meaning they can't be cloned, or that cloning them is an expensive operation), then that's a different matter. My understanding is that that is not the case currently. I really don't understand the problem here. It's fine to be able to send the object into a different state. Lots of objects do this. WebSocket objects can get closed. Windows can get closed. XMLHttpRequest objects can go into several states. And so on. Blobs aren't going to be Transferable -- they don't need to be. You're right: it isn't a big deal to roll a new one. http://dev.w3.org/2006/webapi/FileAPI/#dfn-close Marking this fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 23310] bugs in WebIDL fragments
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23310 Arun a...@mozilla.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Arun a...@mozilla.com --- Fixed. Will ask bzbarsky and heycam about the remaining error using constant methods. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 23431] File API should say what to do with the query string in blob: URLs
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23431 Glenn Maynard gl...@zewt.org changed: What|Removed |Added Status|RESOLVED|REOPENED CC||gl...@zewt.org Resolution|FIXED |--- --- Comment #4 from Glenn Maynard gl...@zewt.org --- I don't think it needs to say anything. Specs say what to do, not what not to do; if it doesn't say to do anything with the query parameter, then nothing is done with the query parameter. The language now in the spec is confusing: it doesn't clearly mean anything, and might be interpreted to mean something wrong. For example, if you parse a blob URL with new URL(blobURL), clearly the .search attribute of the result should include the query, even if it's a blob URL. The vague language must ignore a query string might be interpreted to contradict that, as if the file API spec is implicitly monkey-patching the URL spec. If the intent is to ensure that appending ?foo to a blob URL doesn't affect resolving the resource, then you probably just want to define which parts of the parsed URL are the unique identifier. With the URL spec's terminology, it looks like the identifying part is the scheme data (which doesn't include the query or the fragment). -- You are receiving this mail because: You are on the CC list for the bug.
Re: publish WD of Streams API; deadline Nov 3
OK. There seems to be some disconnect, but I'm fine with waiting for Domenic's proposal first. Takeshi On Thu, Oct 31, 2013 at 7:41 PM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Oct 30, 2013 at 6:04 PM, Domenic Denicola dome...@domenicdenicola.com wrote: I have concrete suggestions as to what such an API could look like—and, more importantly, how its semantics would significantly differ from this one—which I hope to flesh out and share more broadly by the end of this weekend. However, since the call for comments phase has commenced, I thought it important to voice these objections as soon as possible. Given how long we have been trying to figure out streams, waiting a little longer to see Domenic's proposal should be fine I think. No need to start rushing things through the process now. (Although on the flipside at some point we will need to start shipping something.) -- http://annevankesteren.nl/
Re: Splitting Stream into InputStream and OutputStream (was Re: CfC: publish WD of Streams API; deadline Nov 3)
On Thu, Oct 31, 2013 at 4:48 PM, François REMY
francois.remy@outlook.com wrote:
Since JavaScript does not provide a way to check if an object implements
an interface, there should probably exist a way to check that from the API,
like:
Basically it should be sufficient if each API can check type, but yeah
probably useful.
var stream = InputStream(s) // returns “s” if it’s an input stream,
convert is into a stream if possible, or return null
if(stream) { … } else { … }
That’s a great way to convert a string into a stream, for example, in the
case of an API that requires an InputStream and must integrate with older
code that returns a String or a Blob.
Interesting. Maybe also accept an array of strings?
RE: publish WD of Streams API; deadline Nov 3
Agreed. Some of the points listed appear to be things already addressed. Takeshi and I have some feedback on the initial mail, but will wait and provide thoughts on the proposal instead. Looking forward to seeing it. From: tyosh...@google.com Date: Fri, 1 Nov 2013 12:18:47 +0900 To: ann...@annevk.nl CC: dome...@domenicdenicola.com; art.bars...@nokia.com; public-webapps@w3.org Subject: Re: publish WD of Streams API; deadline Nov 3 OK. There seems to be some disconnect, but I'm fine with waiting for Domenic's proposal first. Takeshi On Thu, Oct 31, 2013 at 7:41 PM, Anne van Kesteren ann...@annevk.nlmailto:ann...@annevk.nl wrote: On Wed, Oct 30, 2013 at 6:04 PM, Domenic Denicola dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote: I have concrete suggestions as to what such an API could look like—and, more importantly, how its semantics would significantly differ from this one—which I hope to flesh out and share more broadly by the end of this weekend. However, since the call for comments phase has commenced, I thought it important to voice these objections as soon as possible. Given how long we have been trying to figure out streams, waiting a little longer to see Domenic's proposal should be fine I think. No need to start rushing things through the process now. (Although on the flipside at some point we will need to start shipping something.) -- http://annevankesteren.nl/
Re: CfC: publish WD of Streams API; deadline Nov 3
Along with WebSockets as Aymeric mentioned...WebRTC DataChannels are also missing. And I think Aymeric's point about MediaStream is important too...but there is very strong push-back from within the Media Capture Streams TF that they don't think this is relevant 8/ Also, here's a couple of links for things I've shared/proposed recently related to this. public message http://lists.w3.org/Archives/Public/public-media-capture/2013Sep/0229.html presentation http://www.slideshare.net/robman/web-standards-for-ar-workshop-at-ismar13 code https://github.com/buildar/getting_started_with_webrtc#image_processing_pipelinehtml All thoughts and feedback welcome. roBman On 29/10/13 10:22 PM, Aymeric Vitte wrote: I have suggested some additions/changes in my latest reply to the Overlap thread. The list of streams producers/consumers is not final but obviously WebSockets are missing. Who is coordinating each group that should get involved? MediaStream for example should be based on the Stream interface and all related streams proposals. Regards, Aymeric Le 28/10/2013 16:29, Arthur Barstow a écrit : Feras and Takeshi have begun merging their Streams proposal and this is a Call for Consensus to publish a new WD of Streams API using the updated ED as the basis: https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm Please note the Editors may update the ED before the TR is published (but they do not intend to make major changes during the CfC). Agreement to this proposal: a) indicates support for publishing a new WD; and b) does not necessarily indicate support of the contents of the WD. If you have any comments or concerns about this proposal, please reply to this e-mail by November 3 at the latest. Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. -Thanks, ArtB
RE: CfC: publish WD of Streams API; deadline Nov 3
Yes, WebSockets was missing - I've gone ahead and updated the spec to include it. Thanks for sharing the links, the content is well thought out. In particular, your diagram does a good job summarizing some of the key consumers and producers that come to play regarding Streams. I'll review it in detail. DataChannels also seem like a possible candidate, although I'm not yet very familiar with them. This can be something reviewed and thought through, and added accordingly. Who is coordinating each group that should get involved? MediaStream for example should be based on the Stream interface and all related streams proposals. Once we come to a consensus in the WG what Streams look like and their role, we can begin to coordinate what the impact is on other groups. Thanks, Feras Date: Fri, 1 Nov 2013 16:05:22 +1100 From: rob...@mob-labs.com To: public-webapps@w3.org Subject: Re: CfC: publish WD of Streams API; deadline Nov 3 Along with WebSockets as Aymeric mentioned...WebRTC DataChannels are also missing. And I think Aymeric's point about MediaStream is important too...but there is very strong push-back from within the Media Capture Streams TF that they don't think this is relevant 8/ Also, here's a couple of links for things I've shared/proposed recently related to this. public message http://lists.w3.org/Archives/Public/public-media-capture/2013Sep/0229.html presentation http://www.slideshare.net/robman/web-standards-for-ar-workshop-at-ismar13 code https://github.com/buildar/getting_started_with_webrtc#image_processing_pipelinehtml All thoughts and feedback welcome. roBman On 29/10/13 10:22 PM, Aymeric Vitte wrote: I have suggested some additions/changes in my latest reply to the Overlap thread. The list of streams producers/consumers is not final but obviously WebSockets are missing. Who is coordinating each group that should get involved? MediaStream for example should be based on the Stream interface and all related streams proposals. Regards, Aymeric Le 28/10/2013 16:29, Arthur Barstow a écrit : Feras and Takeshi have begun merging their Streams proposal and this is a Call for Consensus to publish a new WD of Streams API using the updated ED as the basis: https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm Please note the Editors may update the ED before the TR is published (but they do not intend to make major changes during the CfC). Agreement to this proposal: a) indicates support for publishing a new WD; and b) does not necessarily indicate support of the contents of the WD. If you have any comments or concerns about this proposal, please reply to this e-mail by November 3 at the latest. Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. -Thanks, ArtB
Re: CfC: publish WD of Streams API; deadline Nov 3
Sounds good. Thanks. roBman On 1/11/13 4:43 PM, Feras Moussa wrote: Yes, WebSockets was missing - I've gone ahead and updated the spec to include it. Thanks for sharing the links, the content is well thought out. In particular, your diagram does a good job summarizing some of the key consumers and producers that come to play regarding Streams. I'll review it in detail. DataChannels also seem like a possible candidate, although I'm not yet very familiar with them. This can be something reviewed and thought through, and added accordingly. Who is coordinating each group that should get involved? MediaStream for example should be based on the Stream interface and all related streams proposals. Once we come to a consensus in the WG what Streams look like and their role, we can begin to coordinate what the impact is on other groups. Thanks, Feras Date: Fri, 1 Nov 2013 16:05:22 +1100 From: rob...@mob-labs.com To: public-webapps@w3.org Subject: Re: CfC: publish WD of Streams API; deadline Nov 3 Along with WebSockets as Aymeric mentioned...WebRTC DataChannels are also missing. And I think Aymeric's point about MediaStream is important too...but there is very strong push-back from within the Media Capture Streams TF that they don't think this is relevant 8/ Also, here's a couple of links for things I've shared/proposed recently related to this. public message http://lists.w3.org/Archives/Public/public-media-capture/2013Sep/0229.html presentation http://www.slideshare.net/robman/web-standards-for-ar-workshop-at-ismar13 code https://github.com/buildar/getting_started_with_webrtc#image_processing_pipelinehtml All thoughts and feedback welcome. roBman On 29/10/13 10:22 PM, Aymeric Vitte wrote: I have suggested some additions/changes in my latest reply to the Overlap thread. The list of streams producers/consumers is not final but obviously WebSockets are missing. Who is coordinating each group that should get involved? MediaStream for example should be based on the Stream interface and all related streams proposals. Regards, Aymeric Le 28/10/2013 16:29, Arthur Barstow a écrit : Feras and Takeshi have begun merging their Streams proposal and this is a Call for Consensus to publish a new WD of Streams API using the updated ED as the basis: https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm Please note the Editors may update the ED before the TR is published (but they do not intend to make major changes during the CfC). Agreement to this proposal: a) indicates support for publishing a new WD; and b) does not necessarily indicate support of the contents of the WD. If you have any comments or concerns about this proposal, please reply to this e-mail by November 3 at the latest. Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. -Thanks, ArtB
