- From: Eric Uhrhane <ericu@google.com>
- Date: Tue, 9 Mar 2010 13:23:23 -0800
- To: Mike Clement <mikec@google.com>
- Cc: public-device-apis@w3.org
On Tue, Mar 9, 2010 at 1:08 PM, Mike Clement <mikec@google.com> wrote: > Hi Eric, > > [I've tried replying on the public-device-apis list, but nothing I > post seems to show up despite jumping through all of the hoops > (verifying email address and filling out the questionnaire to allow > archiving of my replies). So, I'm sending this directly to you this > time.] > > For text formatting, it would seem that UTF-8 is sufficient. I just > want to make sure there is a pure binary encoding for objects like > images, video and audio files, so that needless encoding to a string > (e.g., data url) can be avoided at all costs. OK, I hear several folks arguing for pure UTF-8 and nobody saying we need anything else, so I'll drop the encoding param. That is an area that could be expanded later if needed. > Also, do you expect the append methods of BlobBuilder to be > expanded beyond text and Blob inputs? For example, how would one > capture the bytes of an image or a video object into a Blob? We have several options there. Either we add more methods to BlobBuilder [or more overloads to append()], or we add a getAsBlob() to ImageData, and the image and video elements. As JavaScript adds native support for binary data types [either through WebGL or elsewise], we'll also need easy ways to convert that to and from Blob. > This is looking great...can't wait to use it! > > --mikec > > On Mon, Mar 8, 2010 at 6:49 PM, Eric Uhrhane <ericu@google.com> wrote: >> On Mon, Mar 8, 2010 at 6:42 AM, Anne van Kesteren <annevk@opera.com> wrote: >>> On Sat, 06 Mar 2010 03:01:13 +0100, Eric Uhrhane <ericu@google.com> wrote: >>>> >>>> I've just posted a new draft of the File Writer API [1], based on the >>>> version I posted in January [2]. I look forward to your feedback. In >>>> the mean time, I'll get going on a clean draft of the FileSystem API. >>> >>> BlobBuilder should have an overloaded append() method rather than two >>> separate methods. That would be more consistent with similar APIs. >> >> Will do. >> >>> It is not defined how the constructor for BlobBuilder ought to work. >> >> I can flesh that out, but there's not a lot to say. Do you mean >> something more than a line like this? >> "When the BlobBuilder() constructor is invoked, the user agent MUST >> return a new BlobBuilder object." >> >>> Why is endings needed? Can't the author handle that himself? >> >> He can emulate a specific platform. If we want him to be able to >> emulate "native", we'd have to tell him what filesystem he's actually >> writing to, which I'd like to avoid. I'm trying to make it easy to >> share files with apps external to the browser. >> >>> Could we get away with not having encoding at all? I.e. always writing UTF-8 >>> octets? >> >> That's certainly an easy place to start. Anybody have strong feelings about it? >> >> Eric >> >> >
Received on Tuesday, 9 March 2010 21:24:13 UTC