Re: File API: lacks model

On Tue, Sep 3, 2013 at 3:07 PM, Arun Ranganathan <arun@mozilla.com> wrote:
> This feedback is a bit vague.

Does http://the-pastry-box-project.net/anne-van-kesteren/2013-september-2/
help illustrate it a bit?


>> I think you should describe the underlying model for Blob/File so
>> other specifications can more easily hook into it. E.g. if I want to
>> represent a File object with a name /x/ and type /y/ there's not a
>> clear way to do that right now. This also leads to issues such as [value space of properties]
>
> Why isn't there a clear way to do that now?

Say I define an API for zip archives and provide an API to get a File
object out of a zip archive. I suppose I could define the relevant
conversions to the attribute values, but it seems there should be an
underlying abstract concept of a file that the File API reflects and
operates on (and other APIs can operate on too).


>> E.g. "A |blob| provides asynchronous access to a byte sequence. A blob
>> has an associated |type| which is a MIME type." (Which could be a link
>> to the variant of MIME type you use.) And then you build the API on
>> top of this model.
>
> I treat http://mimesniff.spec.whatwg.org/ as relatively normative here.  What am I missing?

Mostly that there's no abstract concept of a blob, just an API.
(There's also that mimesniff treats types as a byte sequence, whereas
your specification talks about it as both a byte sequence
(ASCII-encoded string) and string (empty string).


-- 
http://annevankesteren.nl/

Received on Tuesday, 3 September 2013 15:24:22 UTC