> I don't think I can add much to
> http://groups.google.com/group/v8-dev/browse_thread/thread/dba28a81d9215291/ece2b50a3b4022c

The difference would be that the object would be inside a string
instead of an opaque object. For things like HTTP upload requests,
where one needs to parse both ascii headers and an arbitrary binary
body it's much nicer to use a string.

Although Christian's Blob proposal would provide another way of
exposing binary data to the user, it seems best suited to be used as
method of allocating space inside V8 for storage of data for external
objects. Which would also be nice but not for HTTP upload requests.

Though it's totally slow, and uses twice the necessary space, I'm
experimenting with something like:

    len = recv(fd, buf, 4096, 0); // receive data from a socket
    const unsigned char *cbuf = static_cast<const unsigned char*>(buf);
    uint16_t twobytebuf[len];
    for (size_t i = 0; i < len; i++) {
      twobytebuf[i] = cbuf[i];
    }
    Local<String> chunk = String::New(twobytebuf, len);

Which is, just pack the binary data into the first byte of a uint16_t.
This works nicely for the upload use-case.

It seems to me (and correct me if I'm wrong, please) that
ExternalAsciiStringResource provides a way to give one-byte strings to
V8 without copying data, albeit restricted to 8-bit clean data.
Couldn't something like that work for any byte value?

Thanks

--~--~---------~--~----~------------~-------~--~----~
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
-~----------~----~----~----~------~----~------~--~---

Reply via email to