W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2010

Re: New draft of FileWriter API posted

From: Eric Uhrhane <ericu@google.com>
Date: Tue, 9 Mar 2010 13:23:23 -0800
Message-ID: <44b058fe1003091323m2542728bn813c2007418409df@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:42 UTC