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 22:32:49 -0600
Message-ID: <CACQ=j+dsuSWYUtuKBuYRW3aU5UeguqEzt4bZkJ0e0hxGD0K_QA@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Florian Bösch <pyalot@gmail.com>, Robin Berjon <robin@berjon.com>, WebApps WG <public-webapps@w3.org>, Jungkee Song <jungkee.song@samsung.com>
On Wed, Aug 1, 2012 at 2:13 PM, Glenn Adams <glenn@skynav.com> wrote:

> On Wed, Aug 1, 2012 at 2:04 PM, Glenn Maynard <glenn@zewt.org> wrote:
>> Can we please stop saying "lazy blob"?  It's a confused and confusing
>> phrase.  Blobs are "lazy" by design.
>> On Wed, Aug 1, 2012 at 2:26 PM, Glenn Adams <glenn@skynav.com> wrote:
>>> So? Why should lazy blob be specific to HTTP specific semantics when an
>>> arbitrary URL is not specific to HTTP?
>> XHR is no more specific to HTTP than it is to XML.  It serves as the
>> primary JavaScript API for performing generic network fetches.  WebSockets
>> has an entirely different API from blobs, and bringing them up is only
>> derailing the thread.
> 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.

Just to make it clear, I support the idea of defining a "lazy blob"
mechanism. However, I am not satisfied that a solution that is tied solely
to XHR is sufficient. I would like to see a mechanism that supports both
XHR and WS [and others?]. Despite the repeated claims of Florian and GlennM
that it doesn't make sense, etc., I think it does make sense and can be
reasonably (and simply) defined to handle such use cases. If necessary I
can volunteer a strawman to that end. However, I would prefer that DAR or
other proposers take the time to consider this use case and factor it into
their proposals.
Received on Thursday, 2 August 2012 04:33:38 UTC

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