W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: Updates to File API

From: Darin Fisher <darin@chromium.org>
Date: Thu, 13 May 2010 21:32:48 -0700
Message-ID: <AANLkTim5BWB6mbkljfHqfLlp6_BP0ZoZsIuApf8-wcbN@mail.gmail.com>
To: arun@mozilla.com
Cc: David Levin <levin@google.com>, Web Applications Working Group WG <public-webapps@w3.org>, public-device-apis <public-device-apis@w3.org>
Glad to hear that you didn't intend sync access :-)

Can you define the contentType parameter to slice better?  Is that intended
to correspond to the value of a HTTP Content-Type response header?  For
example, can the contentType value include a charset attribute?  It might be
useful to indicate that a slice of a file should be treated as text/html
with a specific encoding.

I'm also a fan of providing a way to specify optional "Content-Disposition"
parameters in the slice call.  It seems to me that Content-Disposition like
Content-Type impacts the way that Blob.url might be interpreted.  It is
useful to enable Blob.url to be able to replicate what you can do with
http:// URLs.  I think this would make it easier for apps to use
http://URLs while online and Blob.url while offline without changing
the rest of
their code.  I'm specifically thinking of use cases like the "download"
links for attachments in webmail apps.

Regards,
-Darin


On Thu, May 13, 2010 at 8:21 AM, Arun Ranganathan <arun@mozilla.com> wrote:

> On 5/13/10 7:37 AM, David Levin wrote:
>
>> On Thu, May 13, 2010 at 5:27 AM, Arun Ranganathan<arun@mozilla.com>
>>  wrote:
>>
>>
>>
>>> Greetings WebApps WG,
>>>
>>> I have updated the editor's draft of the File API to reflect changes that
>>> have been in discussion.
>>>
>>> http://dev.w3.org/2006/webapi/FileAPI
>>>
>>> Notably:
>>>
>>> 1. Blobs now allow further binary data operations by exposing an
>>> ArrayBuffer property that represents the Blob.
>>>
>>>
>>
>> Does this imply *sync* access to the blob data? "new
>> DataArray(blob.blobBuffer).getInt8(0);"
>>
>>
>
> A more sensible way is an additional asynchronous read method on
> FileReader, which is what I should have done in the first place.  Here,
> partial data is going to be an interesting question.  While partial strings
> makes sense (for readAsBinaryString and readAsText), partial ArrayBuffers
> gets us into a different area altogether.  Any thoughts on partial reads
> here?
>
> For now, I've caveated my (pretty major) mistake with an editor's note.
>  I'll update later today with a better way to expose this, but I'm thinking
> something like readAsArrayBuffer on FileReader (with an open question on
> partial reads).
>
>  Also, does it imply the ability to modify the blob contents? (If so, what
>> does this mean when there is a file backing it?)
>> "new DataArray(blob.blobBuffer).setInt8(0, 0);"
>>
>>
>
> I'll let Eric speak to what BlobBuilder might want to do, but I'll strongly
> disallow it in my draft :)
>
> -- A*
>
>> Thanks, dave
>>
>>
>>
>
>
>
Received on Friday, 14 May 2010 04:33:44 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:38 GMT