On Tue, Sep 3, 2013 at 3:07 PM, Arun Ranganathan a...@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/
