Re: Updates to File API

On Fri, May 14, 2010 at 11:52 AM, Arun Ranganathan <arun@mozilla.com> wrote:
> On 5/13/10 9:32 PM, Darin Fisher wrote:
>>
>> Glad to hear that you didn't intend sync access :-)
>>
>
> I have thoughts on Blob and how it should behave (and about the inheritance
> relationship between Blob and File), which is why I left the unfortunate
> error in the editor's draft for now (commented out and caveated).  This is
> the subject of a separate email thread (but don't worry -- while my thoughts
> on Blob and ArrayBuffer may be in some flux, sync access to File objects is
> *always* going to be a no-no, I promise :-) ).
>
> Now aside from the Blob - ArrayBuffer relationship, which I introduced, the
> rest of the changes are in keeping with threads discussing the File API.
>
>> 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 happy to define it better in terms of what it *should* be, but web
> developers are likely to use it in ways that we can't predict, which is why
> "forcing" Content-Types is useful, but weird.  Why exactly do you mean when
> you say that a "slice of a file should be treated as text/html with a
> specific encoding?"  Can you give me a use case that illustrates why this is
> a good way to define this?

I can't speak for Darin, but I'd think the same reasoning that applies
whenever a server adds those headers via HTTP should apply whenever a
client-side app wants to add them to a Blob.url.

>> I'm also a fan of providing a way to specify optional
>> "Content-Disposition"
>> parameters in the slice call.
>
> So I'm really not a Content-Disposition fan, since all the use cases I've
> seen so far seem to be to "force download" behavior (or trigger Download
> Manager).  Is there something I'm missing -- e.g. is there something here
> that FileWriter or BlobBuilder do *not* address, that putting
> Content-Disposition on Blob URLs *does* address?  Sorry if I'm missing
> something obvious.

It is indeed generally intended to trigger Download Manager.  If you
take a look at my use case at [1], the idea is to give web developers
a facility that's just like the one they're already using, so that
anything they do with URLs for files online they can also do with URLs
for Blobs offline/client-side.

The FileWriter spec's a bit up in the air over the same issue; I
haven't yet specced a good way for FileWriter to solve this problem,
so it's hard to say it's going to handle it better.

     Eric

[1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0412.html

Received on Tuesday, 18 May 2010 21:41:37 UTC