On Wed, Aug 1, 2012 at 2:35 PM, Florian Bösch <pyalot@gmail.com> wrote: > On Wed, Aug 1, 2012 at 10:13 PM, Glenn Adams <glenn@skynav.com> wrote: > >> The subject line says Lazy Blob, not Lazy Blob and XHR. For the record, I >> will object to a LazyBlob solution that is tied solely to XHR, so deal with >> it now rather than later. >> > > Then you better get onto specifying a resource/range transfer protocol on > top of websockets alongside with web-server modules/extensions to be able > to understand that protocol, because other than that there is no way that > you'll get what you want. > I don't think so. There is nothing about Blob that would require a data source to implement range access. Blob.slice() does not require the underlying source to provide range access. The source could be read in entirety and buffered by a Blob instance. If a reasonable WS enabled mechanism were defined for a "Lazy Blob" that permitted an application injected range access, then that could be used to perform actual range access. There is no need for WS/WSP to support those semantics directly. I don't particularly care if a default behavior for WS is provided that buffers the entire read stream. It's fine to mandate that an application defined function implement those semantics on a WS instance. My concern is that use of WS be recognized as a legitimate source for filling a lazy blob, and that an author should have an option to use WS, depending on app injected code as needed, instead of mandating XHR for this purpose. I'll leave the details of defining this to the proposers of lazy blob.
Received on Thursday, 2 August 2012 02:55:40 UTC