Re: quick question on xhr2 upload events
Err, yes, now that you point it out, I see that too. I'm not sure why
I didn't see it initially.
Ok, thanks!
- a
On Tue, May 20, 2008 at 7:20 PM, Sam Weinig <[EMAIL PROTECTED]> wrote:
> By my reading, XMLHttpRequestUpload inherits from XMLHttpRequestEventTarget
> (which is what inherits from EventTarget)
> [http://www.w3.org/TR/XMLHttpRequest2/#xmlhttprequest].
> XMLHttpRequestEventTarget is what adds the old style event handler
> attributes, so XMLHttpRequestUpload should support them as well.
>
> -Sam
> On May 20, 2008, at 6:50 PM, Aaron Boodman wrote:
>
> My reading of http://www.w3.org/TR/XMLHttpRequest2/#tracking leads me
> to believe that you can do this:
>
> xhr.upload.addEventListener("progress", function(){}, false);
>
> but not this:
>
> xhr.upload.onprogress = function(){};
>
> That is, XMLHttpRequestUpload implements EventTarget, but not any
> old-style event handler function properties. Is that correct?
>
> - a
>
>
>
quick question on xhr2 upload events
My reading of http://www.w3.org/TR/XMLHttpRequest2/#tracking leads me
to believe that you can do this:
xhr.upload.addEventListener("progress", function(){}, false);
but not this:
xhr.upload.onprogress = function(){};
That is, XMLHttpRequestUpload implements EventTarget, but not any
old-style event handler function properties. Is that correct?
- a
Re: Blobs: An alternate (complementary?) binary data proposal
On Mon, May 12, 2008 at 12:17 AM, Anne van Kesteren <[EMAIL PROTECTED]> wrote: > FWIW, XMLHttpRequest Level 2 already has this functionality in the form of > responseBody: > > http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ > > (send() is also accepts a ByteArray now.) Thanks, I wasn't aware of that. - a
Re: Blobs: An alternate (complementary?) binary data proposal (Was: File IO...)
On Sun, May 11, 2008 at 6:46 PM, Maciej Stachowiak >> It seems better if the read API is just async for this case to prevent >> the problem. > > It can't entirely prevent the problem. If you read a big enough chunk, it > will cause swapping which hits the disk just as much as file reads. Possibly > more, because real file access will trigger OS prefetch heuristics for > linear access. Right, I think the UA has to have ultimate control over the chunk size to prevent this. The length parameters on the read apis I suggested would have to be what the caller desires, but the implementation doesn't necessarily have to honor it. I've changed the parameter names on our wiki page to 'desiredLength' to reflect this. >> Whether XHR spools to disk is an implementation detail, right? Right >> now XHR is not practical to use for downloading large files because >> the only way to access the result is as a string. Also because of >> this, XHR implementations don't bother spooling to disk. But if this >> API were added, then XHR implementations could be modified to start >> spooling to disk if the response got large. If the caller requests >> responseText, then the implementation just does the best it can to >> read the whole thing into a string and reply. But if the caller uses >> responseBlob (or whatever we call it) then it becomes practical to, >> for example, download movie files, modify them, then re-upload them. > > That sounds reasonable for very large files like movies. However, audio and > image files are similar in size to the kinds of text or XML resources that > are currently processed synchronously. In such cases they are likely to > remain in memory. > In general it is sounding like it might be desirable to have at least two > kinds of objects for representing binary data: > > 1) An in-memory, mutable representation with synchronous access. There > should also be a copying API which is possibly copy-on-write for the backing > store. > > 2) A possibly disk-backed representation that offers only asynchronous read > (possibly in the form of representation #1). I agree with this, but I think using Blob/File whatever as the default representation is convenient because you don't need to add multiple getter APIs to things such as XHR (responseBytes and responseBlob). And you probably remove some potential confusion over which getter is correct to use for a given situation. > Both representations could be used with APIs that can accept binary data. In > most cases such APIs only take strings currently. The name of representation > #2 may wish to tie it to being a file, since for anything already in memory > you'd want representation #1. Perhaps they could be called ByteArray and > File respectively. Calling it File seems a little weird to me, particularly in the case of XMLHttpRequest. > Open question: can a File be stored in a SQL database? If > so, does the database store the data or a reference (such as a path or Mac > OS X Alias)? There definitely needs to be a way to store Files locally. I don't have a strong opinion as to whether this should be in the database, or in DOMStorage, or in something new just for files. - a
Re: Blobs: An alternate (complementary?) binary data proposal (Was: File IO...)
On Sun, May 11, 2008 at 5:46 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > Well, that depends on how good the OS buffer cache is at prefetching. But in > general, there would be some disk access. It seems better if the read API is just async for this case to prevent the problem. >> I see what you mean for canvas, but not so much for XHR. It seems like >> a valid use case to want to be able to use XHR to download very large >> files. In that case, the thing you get back seems like it should have >> an async API for reading. > > Hmm? If you get the data over the network it goes into RAM. Why would you > want an async API to in-memory data? Or are you suggesting XHR should be > changed to spool its data to disk? I do not think that is practical to do > for all requests, so this would have to be a special API mode for responses > that are expected to be too big to fit in memory. Whether XHR spools to disk is an implementation detail, right? Right now XHR is not practical to use for downloading large files because the only way to access the result is as a string. Also because of this, XHR implementations don't bother spooling to disk. But if this API were added, then XHR implementations could be modified to start spooling to disk if the response got large. If the caller requests responseText, then the implementation just does the best it can to read the whole thing into a string and reply. But if the caller uses responseBlob (or whatever we call it) then it becomes practical to, for example, download movie files, modify them, then re-upload them. - a
Re: Blobs: An alternate (complementary?) binary data proposal (Was: File IO...)
On Sun, May 11, 2008 at 4:22 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: >> Here's one additional question on how this would work with ByteArray. >> The read API for ByteArray is currently synchronous. Doesn't this mean >> that with large files accessing bytearray[n] could block? > > If the ByteArray were in fact backed by a file, then accessing bytearray[n] > could lead to part of the file being paged in. However, the same is true if > it is backed by RAM that is swapped out. Even accessing uninitialized > zero-fill memory could trap to the kernel, though that's in general not as > bad as hitting disk (whether for swap or file bytes). But expressing the API as an array makes it seem like access is always cheap, encouraging people to just burn through the file in a tight loop. Such loops would actually hit the disk many times, right? > I can see how you may want to have an object to represent a file that can be > handed to APIs directly, but that has only an async read interface for JS. > However, I am pretty sure you would not want to use such an object to > represent binary data returned from an XHR, or the pixel contents of a > . After all, the data is already in memory. So perhaps files need a > distinct object from other forms of binary data, if we wanted to enforce > such a restriction. I see what you mean for canvas, but not so much for XHR. It seems like a valid use case to want to be able to use XHR to download very large files. In that case, the thing you get back seems like it should have an async API for reading. - a
Re: Blobs: An alternate (complementary?) binary data proposal (Was: File IO...)
On Sun, May 11, 2008 at 3:02 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
> Both of these can be addressed by the APIs (including the worker transfer
> mechanism) making a copy, which can use a copy-on-write mechanism to avoid
> actually making a copy in the common case.
Ok, so just so I'm clear, does the following example snippet
accurately reflect how you propose that things work?
var req = new XMLHttpRequest();
req.open("GET", "example", true);
req.onreadystatechange = handleResult;
req.send(null);
function handleResult() {
if (req.readyState != 4) return;
var b1 = req.responseByteArray;
var b2 = b1;
assert(b1 === b2); // they refer to the same object
// print the contents of the array
for (var i = 0; i < b1.length; i++) {
print(b1[i]);
}
b1[0] = 42;
assert(b2[0] == 42);
var worker = window.createWorker("worker.js");
worker.sendMessage(b1); // branches b1
b1[0] = 43; // modification does not affect what got sent to worker
}
// worker.js
worker.onmessage = function(b) {
assert(b[0] == 42);
};
> I'm still not convinced that immutability is good, or that the ECMAScript
> ByteArray proposal can't handle the required use cases.
Here's one additional question on how this would work with ByteArray.
The read API for ByteArray is currently synchronous. Doesn't this mean
that with large files accessing bytearray[n] could block?
- a
Re: Blobs: An alternate (complementary?) binary data proposal (Was: File IO...)
On Sat, May 10, 2008 at 1:18 AM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > I really like the idea of adding consistent APIs for binary data in the many > places in the Web platform that need them. However, I'm not really clear on > why Blobs must be distinct from ByteArrays. The only explanation is: "The > primary difference is that Blobs are immutable*, and can therefore represent > large objects." But I am not sure why immutability is necessary to have the > ability to represent large objects. If you are thinking immutability is > necessary to be able to have large objects memory mapped from disk, then > mmap with a private copy-on-write mapping should solve that problem just > fine. I'm going to defer to Chris Prince on this question, as he is the real man behind this proposal on our team and has thought the most about it. Not knowing much about mmap, it sounds like a fair enough idea to me. It seems like you'd eventually still want to push things back to disk after enough mutation, right? Would writes be synchronous? Would reads? > In fact, immutability seems clearly undesirable for many of these APIs. > Seems like you will want to modify such things and create them from scratch. We agree that you'd want to modify and create blobs, and have a TODO for that in our proposal. However, we were thinking of handling this similarly to how strings are handled in JavaScript. When you modify a blob, you get a new blob instance. But our ideas on this are pretty poorly formed as we don't have as pressing a need as we do for the things we've proposed so far. > I also notice that you used int64 in many of the APIs. JavaScript cannot > represent 64-bit integers in its number type. All JavaScript numbers are > IEEE floating point doubles. This will lose precision at the high end of the > int64 range, which is likely unacceptable for many of these APIs. Thus, if > 64-bit is really needed, then a primitive type will not do. You either need > two int32s or an object type encapsulating this. I think our assumption is that 2^53 is large enough to represent the length of all the blobs going in and out of web apps for the forseeable future. We would just throw when we receive a number that is larger than that saying that it is out of range. Is there a better way to notate this in specs? On Sat, May 10, 2008 at 7:51 PM, Ian Hickson <[EMAIL PROTECTED]> wrote: > On Sun, 11 May 2008, Charles McCathieNevile wrote: >> >> > Do we have the resources to have someone champion this spec? >> >> Are you asking the WG, or Google? > > The Web community as a whole. I don't care which working group (if any) > "owns" it, and I don't have any reason to prefer that Google work on this > rather than anyone else -- my interest is in forwarding the platform as a > whole. :-) I think I might like to do this. What does it involve? Should we take this part offline, Ian? - a
Blobs: An alternate (complementary?) binary data proposal (Was: File IO...)
Hi everyone, > Opera has a proposal for a specification that would revive (and supersede) > the file upload API that has been lingering so long as a work item. The Gears team has also been putting together a proposal for file access which overlaps in some ways with Opera's, but is also orthogonal in some ways: http://code.google.com/p/google-gears/wiki/BlobWebAPIPropsal I would summarize the key differences this way: * We introduce a new interface - a blob - that represents an immutable chunk of (potentially large) binary data * We propose adding the ability to get and send blobs to many different APIs, including XHR, the element, database, , etc. * We attempt far less interaction with the filesystem (just extending the input element and allowing exporting a blob to a file). To answer one of Maciej's questions from the other thread, we intend this for use on the open web and do not intend for it to require any particular security authorization. We would also love feedback, and would like to work with any interested vendors to iterate this to something others would implement. Thanks, - a
Geolocation API proposal
Hello, I work on Google Gears team. If you're not familiar with what Gears is, you can learn more here: http://code.google.com/apis/gears. We've been working on an API that will allow an application to obtain (with permission) the user's current location. I posted this to the WhatWG mailing list, but it was suggested that this might be a more appropriate place. Anyway, here's our current design: http://code.google.com/p/google-gears/wiki/LocationAPI We think there's a lot of potential for interesting applications with a API like this. Some examples would be recommendations for nearby restaurants, turn by turn directions, or city walking tours. Are there any other vendors interested in implementing something like this? If so, we'd like to work together to come up with a standard. Otherwise, I'll just put this out there for comment for the time being. We'd appreciate any feedback on the design, one way or the other. Thanks, -- Aaron Boodman
