Hi Glenn,
var xhr = new XMLHttpRequest();
xhr.open(GET, resource.jpg);
var urlObject = xhr.getURLObject();
var newURL = URL.getObjectURL(urlObject);
img.src = newURL;
It's neat and I like the idea, too. However, there is a reason that I prefer
our blob approaches:
=== Another XHR
On Tue, Aug 7, 2012 at 4:07 AM, Jungkee Song jungkee.s...@samsung.comwrote:
window.intent.postResult(blob);
From totally client developer's point of view, who perhaps do not care the
underlying details at all, it is absolutely transparent to use the obtained
blob as they used to deal with.
On Aug 7, 2012, at 17:06 , Glenn Maynard wrote:
A different option, equivalent to users, is to make URLObject a base class of
Blob. URLObject would replace Blob in methods like FileReader.readAsDataURL,
createObjectURL and all other places where methods can work without knowing
the size in
- URLObject represents a resource that can be fetched, FileReader'd,
createObjectURL'd, and cloned, but without any knowledge of the contents
(no size attribute, no type attribute) and no slice() as URLObjects may
not be seekable.
- Blob extends URLObject, adding size, type, slice(), and
On Tue, Aug 7, 2012 at 6:53 PM, Jungkee Song jungkee.s...@samsung.comwrote:
- URLObject represents a resource that can be fetched, FileReader'd,
createObjectURL'd, and cloned, but without any knowledge of the contents
(no size attribute, no type attribute) and no slice() as URLObjects may
On Tue, Aug 7, 2012 at 8:14 PM, Glenn Adams gl...@skynav.com wrote:
I would suggest using a different name than URLObject. I think that name
will cause a lot of head scratching.
No disagreement there; that was just a placeholder. I'd suggest waiting
for further input from Anne, Jonas and
On Tue, Aug 7, 2012 at 7:38 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Aug 7, 2012 at 8:14 PM, Glenn Adams gl...@skynav.com wrote:
I would suggest using a different name than URLObject. I think that
name will cause a lot of head scratching.
No disagreement there; that was just a
On Aug 2, 2012, at 14:51 , Tobie Langel wrote:
On 8/2/12 2:29 PM, Robin Berjon ro...@berjon.com wrote:
On Aug 2, 2012, at 10:45 , Tobie Langel wrote:
On 8/1/12 10:04 PM, Glenn Maynard gl...@zewt.org wrote:
Can we please stop saying lazy blob? It's a confused and confusing
phrase. Blobs are
On Aug 2, 2012, at 17:45 , Glenn Adams wrote:
Are you saying I am objecting for the fun of it? Where did I say I don't like
the idea? You'd best reread my messages.
For the fun of it is an expression. You don't like the idea that the
solutions proposed in this thread are restricted to what is
Hi Glenn,
On Aug 3, 2012, at 01:23 , Glenn Maynard wrote:
I'd suggest the following.
- Introduce an interface URLObject (bikeshedding can come later), with no
methods. This object is supported by structured clone.
- Add XMLHttpRequest.getURLObject(optional data), which returns a new
On Mon, Aug 6, 2012 at 6:53 AM, Robin Berjon ro...@berjon.com wrote:
So if you do have a use case, by all means please share it. If not, I
maintain that you simply have no grounds for objection.
I did share a couple of use cases in my response to Ian:
On Thu, Aug 2, 2012 at 11:39 AM, Glenn
On Mon, 6 Aug 2012, Glenn Adams wrote:
I did share a couple of use cases in my response to Ian:
I will let Robin and Jungkee reply to the more general use case
requirements. As far as WS is concerned, I don't see any impact of
this thread on the WS API or WSP specs, its really simply
On Mon, Aug 6, 2012 at 11:27 AM, Ian Hickson i...@hixie.ch wrote:
On Mon, 6 Aug 2012, Glenn Adams wrote:
I did share a couple of use cases in my response to Ian:
I will let Robin and Jungkee reply to the more general use case
requirements. As far as WS is concerned, I don't see any
On Wed, Aug 1, 2012 at 7:59 AM, Robin Berjon ro...@berjon.com wrote:
Hi all,
with the likes of postMessage and Web Intents that we are getting access to
now, it is increasingly common that data may flow from a server to an
in-browser page, that may then pass that data on to another
On Mon, Aug 6, 2012 at 8:39 PM, Glenn Adams gl...@skynav.com wrote:
I'll leave the translation of IM protocol to user facing use case as
homework for the reader. It is trivial. My intent is to show a use case
where one would use a persistent connection and a series of send/response
messages
On Mon, Aug 6, 2012 at 1:31 PM, Florian Bösch pya...@gmail.com wrote:
On Mon, Aug 6, 2012 at 8:39 PM, Glenn Adams gl...@skynav.com wrote:
I'll leave the translation of IM protocol to user facing use case as
homework for the reader. It is trivial. My intent is to show a use case
where one
On Mon, Aug 6, 2012 at 2:16 PM, Jonas Sicking jo...@sicking.cc wrote:
Since it appears my original email went unnoticed, here's another try.
I think what you are looking for is Streams. The resulting code would
be something like:
var xhr = new XMLHttpRequest();
xhr.responseType = stream;
On Mon, Aug 6, 2012 at 9:33 PM, Glenn Adams gl...@skynav.com wrote:
The same reason that a remote blob would be useful with XHR.
Since you're steadfastly refusing to detail your use case, that'll just
mean none to me.
On Mon, Aug 6, 2012 at 12:33 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Aug 6, 2012 at 2:16 PM, Jonas Sicking jo...@sicking.cc wrote:
Since it appears my original email went unnoticed, here's another try.
I think what you are looking for is Streams. The resulting code would
be something
On Mon, Aug 6, 2012 at 2:06 PM, Florian Bösch pya...@gmail.com wrote:
On Mon, Aug 6, 2012 at 9:33 PM, Glenn Adams gl...@skynav.com wrote:
The same reason that a remote blob would be useful with XHR.
Since you're steadfastly refusing to detail your use case, that'll just
mean none to me.
I
On Mon, Aug 6, 2012 at 3:28 PM, Jonas Sicking jo...@sicking.cc wrote:
Arthur was awesome enough to dig it up:
Thanks.
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1494.html
http://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm
Though we would need to modify that
On Wed, Aug 1, 2012 at 7:59 AM, Robin Berjon ro...@berjon.com wrote:
Hi all,
with the likes of postMessage and Web Intents that we are getting access to
now, it is increasingly common that data may flow from a server to an
in-browser page, that may then pass that data on to another
On Wed, Aug 1, 2012 at 10:44 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 1 Aug 2012, Glenn Adams wrote:
Of course, implementers are free to ignore whatever they want, but last
time I checked, the W3C was a consensus based standards organization
which means agreement needs to be reached
On Thu, 2 Aug 2012, Glenn Adams wrote:
I don't really care about the XHR side of this (happy to let Anne
figure that out), but since WebSockets was mentioned: what's the use
case that involves Web Socket? I don't really understand what problem
we're trying to solve here.
i would
On Thu, Aug 2, 2012 at 1:04 AM, Ian Hickson i...@hixie.ch wrote:
On Thu, 2 Aug 2012, Glenn Adams wrote:
I don't really care about the XHR side of this (happy to let Anne
figure that out), but since WebSockets was mentioned: what's the use
case that involves Web Socket? I don't really
On Aug 1, 2012, at 21:26 , Glenn Adams wrote:
So? Why should lazy blob be specific to HTTP specific semantics when an
arbitrary URL is not specific to HTTP?
No one said that they would have to be HTTP specific, but I agree with Florian
that I don't see how it could apply to WS. It could, for
On Aug 1, 2012, at 22:13 , Glenn Adams 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.
Objections need to be built on something — just objecting for the fun
On 8/1/12 10:04 PM, Glenn Maynard gl...@zewt.org wrote:
Can we please stop saying lazy blob? It's a confused and confusing
phrase. Blobs are lazy by design.
Yes. Remote blob is more accurate and should help think about this
problem in a more meaningful way.
--tobie
On Thu, 02 Aug 2012 10:45:03 +0200, Tobie Langel to...@fb.com wrote:
On 8/1/12 10:04 PM, Glenn Maynard gl...@zewt.org wrote:
Can we please stop saying lazy blob? It's a confused and confusing
phrase. Blobs are lazy by design.
Yes. Remote blob is more accurate and should help think about
On Aug 2, 2012, at 10:45 , Tobie Langel wrote:
On 8/1/12 10:04 PM, Glenn Maynard gl...@zewt.org wrote:
Can we please stop saying lazy blob? It's a confused and confusing
phrase. Blobs are lazy by design.
Yes. Remote blob is more accurate and should help think about this
problem in a more
Hi Glenn and all,
From: Glenn Maynard [mailto:gl...@zewt.org]
Sent: Thursday, August 02, 2012 12:45 AM
To: Robin Berjon
Cc: WebApps WG; Jungkee Song
Subject: Re: Lazy Blob
On Wed, Aug 1, 2012 at 9:59 AM, Robin Berjon ro...@berjon.com wrote:
var bb = new BlobBuilder()
, blob
On 8/2/12 2:29 PM, Robin Berjon ro...@berjon.com wrote:
On Aug 2, 2012, at 10:45 , Tobie Langel wrote:
On 8/1/12 10:04 PM, Glenn Maynard gl...@zewt.org wrote:
Can we please stop saying lazy blob? It's a confused and confusing
phrase. Blobs are lazy by design.
Yes. Remote blob is more
On Thu, Aug 2, 2012 at 2:36 AM, Robin Berjon ro...@berjon.com wrote:
On Aug 1, 2012, at 22:13 , Glenn Adams 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.
On Thu, Aug 2, 2012 at 9:51 AM, Florian Bösch pya...@gmail.com wrote:
On Thu, Aug 2, 2012 at 5:45 PM, Glenn Adams gl...@skynav.com wrote:
No it hasn't. If you want a real world use case it is this: my
architectural constraints as an author for some particular usage requires
that I use WS
On Thu, Aug 2, 2012 at 10:04 AM, Florian Bösch pya...@gmail.com wrote:
On Thu, Aug 2, 2012 at 5:58 PM, Glenn Adams gl...@skynav.com wrote:
All WS usage requires a particular (application specific) implementation
on the server, does it not? Notwithstanding that fact, such usage will fall
into
On Thu, 2 Aug 2012, Glenn Adams wrote:
Sorry, I was vague. What I mean is what user-facing problem is it that
we're trying to solve?
see DAR's initial message in this thread; bringing WS into scope doesn't
change the problem statement, it merely enlarges the solution space, or
keeps
On Thu, Aug 2, 2012 at 11:01 AM, Ian Hickson i...@hixie.ch wrote:
On Thu, 2 Aug 2012, Glenn Adams wrote:
Sorry, I was vague. What I mean is what user-facing problem is it that
we're trying to solve?
see DAR's initial message in this thread; bringing WS into scope doesn't
change
On Thu, 2 Aug 2012, Glenn Adams wrote:
I was referring to
http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0264.html
While that message does not specifically refer to a full-duplex comm
path, it states the general problem in terms of It is increasingly
common that data may
On Thu, Aug 2, 2012 at 11:09 AM, Florian Bösch pya...@gmail.com wrote:
On Thu, Aug 2, 2012 at 6:37 PM, Glenn Adams gl...@skynav.com wrote:
I am not proposing a particular browser supported semantic for a
specific implementation on the server. I have suggested, by way of
example, two
On Thu, Aug 2, 2012 at 11:19 AM, Ian Hickson i...@hixie.ch wrote:
On Thu, 2 Aug 2012, Glenn Adams wrote:
I was referring to
http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0264.html
While that message does not specifically refer to a full-duplex comm
path, it states the
On Thu, 2 Aug 2012, Glenn Adams wrote:
Are you asking for use cases for a remote/lazy blob in general? i.e., as
would apply to the proposed XHR usage and any other underlying supported
data source? or are you asking about high level use cases that are
particular to a WS binding but not an
On Thu, Aug 2, 2012 at 11:26 AM, Ian Hickson i...@hixie.ch wrote:
On Thu, 2 Aug 2012, Glenn Adams wrote:
Are you asking for use cases for a remote/lazy blob in general? i.e., as
would apply to the proposed XHR usage and any other underlying supported
data source? or are you asking about
I'd suggest the following.
- Introduce an interface URLObject (bikeshedding can come later), with no
methods. This object is supported by structured clone.
- Add XMLHttpRequest.getURLObject(optional data), which returns a new
URLObject. This can only be called while XMLHttpRequest is in the
On Wed, Aug 1, 2012 at 9:50 PM, Glenn Adams gl...@skynav.com wrote:
Further, a default behavior in the absence of such an injection might be
defined simply to read data from the WS and stuff into the blob.
Which kind of defeats the purpose because you wanted to read ranges, so not
a whole
On Wed, Aug 1, 2012 at 6:51 PM, Glenn Adams gl...@skynav.com wrote:
I'm questioning defining a LazyBlob that is solely usable with XHR. It
would be better to have a more generic version IMO.
Websockets have no content semantics, therefore any lazy content
negotiating reader cannot deal with
On Wed, Aug 1, 2012 at 6:40 PM, Glenn Adams gl...@skynav.com wrote:
Why restrict to XHR? How about WebSocket as data source?
Websockets support array buffers and therefore by extension any blob/file
object. However as a stream oriented API websockets have no content
aquisition, negotation,
On Thu, Aug 2, 2012 at 5:45 PM, Glenn Adams gl...@skynav.com wrote:
No it hasn't. If you want a real world use case it is this: my
architectural constraints as an author for some particular usage requires
that I use WS rather than XHR. I wish to have support for the construct
being discussed
On Thu, Aug 2, 2012 at 6:37 PM, Glenn Adams gl...@skynav.com wrote:
I am not proposing a particular browser supported semantic for a
specific implementation on the server. I have suggested, by way of
example, two particular patterns be supported independently of any such
implementation. I did
On Wed, Aug 1, 2012 at 9:26 PM, Glenn Adams gl...@skynav.com wrote:
So? Why should lazy blob be specific to HTTP specific semantics when an
arbitrary URL is not specific to HTTP?
Reading a resource at arbitrary locations requires two things:
1) That a resource is understood as a container of
On Thu, Aug 2, 2012 at 5:58 PM, Glenn Adams gl...@skynav.com wrote:
All WS usage requires a particular (application specific) implementation
on the server, does it not? Notwithstanding that fact, such usage will fall
into certain messaging patterns. I happened to give an example of two
On Wed, Aug 1, 2012 at 10:13 PM, Glenn Adams gl...@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
On Wed, Aug 1, 2012 at 7:57 PM, Glenn Adams gl...@skynav.com wrote:
blob =
bb.getBlobFromURL(ws://specifiction.com/image/kitten.pnghttp://specifiction.com/kitten.png
)
There is no application layer transfer protocol inherent in websockets.
Requesting a resource does not have any inherent
The URLObject proposal is a pretty slick way of cooking up a request in
contextA for later (and all manner of) retrieval in contextB.
On Thu, Aug 2, 2012 at 4:23 PM, Glenn Maynard gl...@zewt.org wrote:
I'd suggest the following.
- Introduce an interface URLObject (bikeshedding can come
On Wed, Aug 1, 2012 at 9:59 AM, Robin Berjon ro...@berjon.com wrote:
var bb = new BlobBuilder()
, blob = bb.getBlobFromURL(http://specifiction.com/kitten.png;, GET, {
Authorization: Basic DEADBEEF });
Everything is the same as the previous version but the method and some
headers can be
On Wed, Aug 1, 2012 at 9:44 AM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Aug 1, 2012 at 9:59 AM, Robin Berjon ro...@berjon.com wrote:
var bb = new BlobBuilder()
, blob = bb.getBlobFromURL(http://specifiction.com/kitten.png;, GET,
{ Authorization: Basic DEADBEEF });
Everything is the
On Wed, Aug 1, 2012 at 10:46 AM, Florian Bösch pya...@gmail.com wrote:
On Wed, Aug 1, 2012 at 6:40 PM, Glenn Adams gl...@skynav.com wrote:
Why restrict to XHR? How about WebSocket as data source?
Websockets support array buffers and therefore by extension any blob/file
object. However as a
On Wed, Aug 1, 2012 at 11:13 AM, Florian Bösch pya...@gmail.com wrote:
On Wed, Aug 1, 2012 at 6:51 PM, Glenn Adams gl...@skynav.com wrote:
I'm questioning defining a LazyBlob that is solely usable with XHR. It
would be better to have a more generic version IMO.
Websockets have no content
On Aug 1, 2012, at 8:44 AM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Aug 1, 2012 at 9:59 AM, Robin Berjon ro...@berjon.com wrote:
var bb = new BlobBuilder()
, blob = bb.getBlobFromURL(http://specifiction.com/kitten.png;, GET, {
Authorization: Basic DEADBEEF });
Everything is the same
On Wed, Aug 1, 2012 at 12:03 PM, Florian Bösch pya...@gmail.com wrote:
On Wed, Aug 1, 2012 at 7:57 PM, Glenn Adams gl...@skynav.com wrote:
blob =
bb.getBlobFromURL(ws://specifiction.com/image/kitten.pnghttp://specifiction.com/kitten.png
)
There is no application layer transfer protocol
Maybe another XHR based way to phrase this: define a new response type for
XHR that results in the construction of a lazyBlob. I guess that's similar
to the more explicit xhr.makeLazyBlob() method, but allows its construction
to be async, and for greater reuse of the same signaling for progress
On Wed, Aug 1, 2012 at 1:36 PM, Florian Bösch pya...@gmail.com wrote:
On Wed, Aug 1, 2012 at 9:26 PM, Glenn Adams gl...@skynav.com wrote:
So? Why should lazy blob be specific to HTTP specific semantics when an
arbitrary URL is not specific to HTTP?
So if you want to have a lazy reader on
On Wed, Aug 1, 2012 at 1:47 PM, Glenn Adams gl...@skynav.com wrote:
On Wed, Aug 1, 2012 at 1:36 PM, Florian Bösch pya...@gmail.com wrote:
On Wed, Aug 1, 2012 at 9:26 PM, Glenn Adams gl...@skynav.com wrote:
So? Why should lazy blob be specific to HTTP specific semantics when an
arbitrary
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 gl...@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
On Wed, Aug 1, 2012 at 1:54 PM, Florian Bösch pya...@gmail.com wrote:
On Wed, Aug 1, 2012 at 9:50 PM, Glenn Adams gl...@skynav.com wrote:
Further, a default behavior in the absence of such an injection might be
defined simply to read data from the WS and stuff into the blob.
Which kind of
On Wed, Aug 1, 2012 at 2:04 PM, Glenn Maynard gl...@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 gl...@skynav.com wrote:
So? Why should lazy blob be specific to HTTP
On 8/1/12 11:44 AM, Glenn Maynard wrote:
Ideally, a new responseType could be added to XHR which operates like
blob, except instead of reading the whole resource, it just performs a
HEAD to retrieve the response length and immediately returns the Blob,
which can be read to perform further
On Wed, Aug 1, 2012 at 8:16 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Unless the server is one of the common ones with broken HEAD handling. Or
unless the resource is served with Content-Encoding:gzip, in which case
your Content-Range is all sorta broken. :(
Those could fall back on
On Wed, Aug 1, 2012 at 2:35 PM, Florian Bösch pya...@gmail.com wrote:
On Wed, Aug 1, 2012 at 10:13 PM, Glenn Adams gl...@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
On Wed, Aug 1, 2012 at 9:54 PM, Glenn Adams gl...@skynav.com wrote:
I don't particularly care if a default behavior for WS is provided that
buffers the entire read stream.
Sorry, but that doesn't make sense. You don't access a message-based
protocol (Web Sockets) using a character-based API
On Wed, Aug 1, 2012 at 9:35 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Aug 1, 2012 at 9:54 PM, Glenn Adams gl...@skynav.com wrote:
I don't particularly care if a default behavior for WS is provided that
buffers the entire read stream.
Sorry, but that doesn't make sense. You don't
On 8/1/12 9:50 PM, Glenn Maynard wrote:
(if the broken HEAD cases are detectable, anyway)
I wish.
Some of them are, but a lot are not. We used to use HEAD for things
like save link as in Firefox (for prompting the user for a filename
and such), but had to stop because it was broken so
On Wed, Aug 1, 2012 at 2:13 PM, Glenn Adams gl...@skynav.com wrote:
On Wed, Aug 1, 2012 at 2:04 PM, Glenn Maynard gl...@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
On Wed, 1 Aug 2012, Glenn Adams wrote:
Of course, implementers are free to ignore whatever they want, but last
time I checked, the W3C was a consensus based standards organization
which means agreement needs to be reached on what specs go out the door
and what are in those specs.
Doesn't
73 matches
Mail list logo
