W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Re: Lazy Blob

From: Glenn Adams <glenn@skynav.com>
Date: Wed, 1 Aug 2012 20:54:52 -0600
Message-ID: <CACQ=j+dvL2Q2nOH95UQCs-Ot6_TPDRtwwGOiFnYAWqga-u-RkQ@mail.gmail.com>
To: Florian Bösch <pyalot@gmail.com>
Cc: Glenn Maynard <glenn@zewt.org>, Robin Berjon <robin@berjon.com>, WebApps WG <public-webapps@w3.org>, Jungkee Song <jungkee.song@samsung.com>
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
Received on Thursday, 2 August 2012 02:55:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:37 UTC