[FileAPI] Latest Revision of Editor's Draft

[Arun Ranganathan-4]

The latest revision of the FileAPI editor's draft is available here:

http://dev.w3.org/2006/webapi/FileAPI/

These changes constitute a substantial reworking of the original API
along the lines of the "Alternative File API" proposal [1].  There are
also some additional changes that are worth pointing out explicitly:

1. This editor's draft now resides in a new location in CVS.  
Essentially, previous repository names had "FileUpload" in them and were
confusing, since the API in question had less to do with *uploading a
file* than *reading* a file.  "FileAPI" is shorter and more intuitive
(and better describes what we're doing).  Previous drafts are worth
keeping as historical artifacts reflecting the decision making of the
WG, and so now include a caveat on them pointing them to the draft above.

2. Interface names have changed (notably FileData --> Blob) since the
underlying FileData interface had uses on the platform beyond a file
read API.  "Blob" as an interface name was first introduced by a Google
Gears API, which I cite as an informative reference.

3. The event model resembles that of XHR2, with a few differences.  
Notably, the APIs differ in their use of the 'loadend' ProgressEvent.

4. A suggestion to *not* have a separate scheme ("filedata:") in lieu of
urn:uuid:<uuid>[2] has been the basis of a rewrite of that feature in
this version of the specification.

I don't anticipate the event model will be controversial, having seen a
fair amount of discussion on the listserv.  But I do anticipate feedback
about 4., as well as the remaining editor's notes.

Looking forward to discussion of this API on this listserv and at the
upcoming TPAC :)

-- A*
[1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0565.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0091.html

[Jonas Sicking-2]

On Mon, Oct 26, 2009 at 5:24 AM, Arun Ranganathan <arun@...> wrote:
> The latest revision of the FileAPI editor's draft is available here:
>
> http://dev.w3.org/2006/webapi/FileAPI/

A few comments:

* loadend should fire after load/error/abort.
* I'm not sure i love the name 'fileData'. Maybe 'result' or simply
'data' is better.
* Whatever the name, I don't see why 'fileData' should only be
readable while an event is being fired. That seems unnecessarily
complicated, doesn't match XHR and seems less useful.
* fileData should probably be null rather than the empty string during
on error and before data is read.
* The second argument to 'splice' should be called 'length' rather
than 'offset'.
* I think someone had brought up a good argument for *not* throwing
when slice is called with start+offset > size. One of the main use
cases for slice is to slice up a file in several chunks when sending
with XHR. When that is done it's easy to end up with rounding errors
resulting in a slightly to large length being requested. In this case
it makes sense to just clamp to size rather than throwing an error.

/ Jonas

[Ian Hickson]

On Mon, 26 Oct 2009, Arun Ranganathan wrote:
>
> 2. Interface names have changed (notably FileData --> Blob) since the
> underlying FileData interface had uses on the platform beyond a file
> read API. "Blob" as an interface name was first introduced by a Google
> Gears API, which I cite as an informative reference.

Updated HTML5 and related specs.


> 3. The event model resembles that of XHR2, with a few differences.  
> Notably, the APIs differ in their use of the 'loadend' ProgressEvent.

I think this spec needs examples. I think the examples would show that the
current design requires far too many lines of code to do something that
really should only need one or two statements.

(I think XHR is a very poor model to follow.)


> 4. A suggestion to *not* have a separate scheme ("filedata:") in lieu of
> urn:uuid:<uuid>[2] has been the basis of a rewrite of that feature in
> this version of the specification.

I would like to see implementation feedback on this. I don't understand
why we would want to assign semantics to urn:uuid: URLs that are so
specific -- that seems completely wrong. It also seems really awkward from
an implementation perspective to forgo the normal extension mechanism
(schemes) and have implementations give special (and non-trivial)
semantics to a subset of another scheme. Why are we doing this?

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Arun Ranganathan-4]

Jonas Sicking wrote:

> On Mon, Oct 26, 2009 at 5:24 AM, Arun Ranganathan <arun@...> wrote:
>  
>> The latest revision of the FileAPI editor's draft is available here:
>>
>> http://dev.w3.org/2006/webapi/FileAPI/
>>    
>
> A few comments:
>
> * loadend should fire after load/error/abort.
>  

Currently it *only* fires when error and abort events fire.  I felt that
'load' was sufficient for successful reads into memory, while 'loadend'
was useful for unsuccessful ones.  This differs from XHR2's definition
of 'loadend'[1]:

"When the request has completed (either in success or failure)." [1]

When loadend was removed from media elements [2] I wished to determine
whether it was event overkill to also fire at successful reads.   Sounds
like you want it back for successful reads as well?


> * I'm not sure i love the name 'fileData'. Maybe 'result' or simply
> 'data' is better.
>  

I'm happy to change it to a better name, but chose 'fileData' since in
the original version of the draft, with asynchronous callbacks [3], we
had an interface called FileData which represented the actual file data
(in the present and current version of the editor's draft --
http://dev.w3.org/2006/webapi/FileAPI/ -- FileData is called Blob) .  Of
the two names you suggest,  do you feel strongly about one over the
others?

I'm not sure I love 'result' (it isn't intuitive as a response to a
read), and 'data' is used in other contexts on the platform and so may
be confusing.  If you feel strongly (stronger than a 'maybe' ;-) ) about
a different name, I'm happy to change it.

> * Whatever the name, I don't see why 'fileData' should only be
> readable while an event is being fired. That seems unnecessarily
> complicated, doesn't match XHR and seems less useful.
>  

Nothing in the present draft prohibits that -- I only left an editor's
note as an open question.  I agree with you about the desired behavior,  
and so I'll remove the editor's note.

> * fileData should probably be null rather than the empty string during
> on error and before data is read.
>  

Done
> * The second argument to 'splice' should be called 'length' rather
> than 'offset'.
>  

Done
> * I think someone had brought up a good argument for *not* throwing
> when slice is called with start+offset > size. One of the main use
> cases for slice is to slice up a file in several chunks when sending
> with XHR. When that is done it's easy to end up with rounding errors
> resulting in a slightly to large length being requested. In this case
> it makes sense to just clamp to size rather than throwing an error.
>  

OK -- sounds like slice should NOT throw an INDEX_SIZE_ERR at all, and
only clamp on size?
> / Jonas
>  

Current editor's draft: http://dev.w3.org/2006/webapi/FileAPI/

[1] http://www.w3.org/TR/XMLHttpRequest2/#loadend-event
[2]
http://dev.w3.org/cvsweb/html5/spec/Overview.html?r1=1.3290&r2=1.3291&f=h
[3] http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html

[Arun Ranganathan-4]

Ian Hickson wrote:

>> 3. The event model resembles that of XHR2, with a few differences.  
>> Notably, the APIs differ in their use of the 'loadend' ProgressEvent.
>>    
>
> I think this spec needs examples. I think the examples would show that the
> current design requires far too many lines of code to do something that
> really should only need one or two statements.
>
> (I think XHR is a very poor model to follow.)
>
>  

Currently, the introduction contains an example [1], which illustrates
the event model design (use of FileReader).  Are there examples above
and beyond what that illustrates that you'd like to see?  If so,
suggestions are welcome.  I've committed to updating the specification
with an example for Worker Threads, which makes use of a synchronous
read API.

No argument from me that the current design in the editor's draft [1]
requires more lines of code to read a file than the *initial* editor's
draft which contained read methods with callbacks [2], but a lengthy
thread (e.g. follow [3][4][5] and beyond) covering the desirability of
callbacks vs. events (and particularly, progress events) resulted in the
strawperson for the existing design [6].  I'll note that you didn't
weigh in on these discussions then.

I disagree with you that this constitutes "far too many lines of code"
but I do agree with you that the present design is a more complex model
than that in the original editor's draft [2].  The advantages are that
it allows progress events, as well as the general benefits of an
EventTarget (for adding event listeners).  There is also a separation of
files from the objects that read from them.  There are definite
trade-offs between simplicity and more complexity, which I've voiced
before, but I am reconciled to the current proposal [1] since it covers
desirable use cases.  There was general support for this, including
recognition of the trade-offs (e.g. see [7][8], amongst others) which is
why I proceeded with the current proposal.  The added complexity isn't
*that great* and the model enables more power than the original proposal
[2].

Regarding emulating XHR: general developer feedback we got was that it
was a desirable model to follow, and that developers were familiar with
it.  One suggestion, floated here, even suggested extending *XHR itself*
to read files [9] (which there was general disagreement with, given the
impulse to separate network APIs from file ones, which don't require
network capabilities).  Given that we've gone down the path of using
progress events and separating files from the objects that read from
them, I do not agree that XHR is a very poor model to follow; rather, it
is a popular model with a fair amount of developer familiarity, and has
been wrapped by several libraries to offer even higher level
abstractions for network activity.

>> 4. A suggestion to *not* have a separate scheme ("filedata:") in lieu of
>> urn:uuid:<uuid>[2] has been the basis of a rewrite of that feature in
>> this version of the specification.
>>    
> I would like to see implementation feedback on this. I don't understand
> why we would want to assign semantics to urn:uuid: URLs that are so
> specific -- that seems completely wrong. It also seems really awkward from
> an implementation perspective to forgo the normal extension mechanism
> (schemes) and have implementations give special (and non-trivial)
> semantics to a subset of another scheme. Why are we doing this?
>  

In general, this area is the one most likely to be fraught with contention.

For what it's worth, we started with a separate scheme called filedata:  
[2], modeled after urn:uuid.  (And you don't strictly need UUIDs -- any
identifier will do -- but it seemed advantageous to standardize an
easily coinable identifier).   Can you explain why a *new scheme* is
better than reusing an *existing scheme?*  The use case -- to have
"time-bound" ways to access file data on the web platform everywhere a
URL is used -- can probably be addressed with an existing scheme.  
Coining a new scheme is non-trivial; is it absolutely necessary here?

Your point about reusing a subset of HTTP for urn:uuid is valid, though,
and I've left this as an editor's note.  We could have this behave like
a new and improved file:///, and specify how it works *without* status
codes.  We could merely specify that the urn:uuid resource is retrieved
if valid (namely, that it meets the origin and lifetime stipulations),
or nothing is returned if invalid.  Would this allay your queasiness
about reusing urn:uuid?  Use cases for why request-response status codes
are needed for file retrieval would be useful.

-- A*
[1] http://dev.w3.org/2006/webapi/FileAPI/
[2] http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0539.html
[4] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0547.html
[5] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0551.html
[6] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0565.html
[7] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0664.html
[8] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0685.html
[9] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0492.html

[Jonas Sicking-2]

On Tue, Oct 27, 2009 at 11:58 AM, Arun Ranganathan <arun@...> wrote:

> Jonas Sicking wrote:
>>
>> On Mon, Oct 26, 2009 at 5:24 AM, Arun Ranganathan <arun@...>
>> wrote:
>>
>>>
>>> The latest revision of the FileAPI editor's draft is available here:
>>>
>>> http://dev.w3.org/2006/webapi/FileAPI/
>>>
>>
>> A few comments:
>>
>> * loadend should fire after load/error/abort.
>>
>
> Currently it *only* fires when error and abort events fire.  I felt that
> 'load' was sufficient for successful reads into memory, while 'loadend' was
> useful for unsuccessful ones.  This differs from XHR2's definition of
> 'loadend'[1]:
>
> "When the request has completed (either in success or failure)." [1]
>
> When loadend was removed from media elements [2] I wished to determine
> whether it was event overkill to also fire at successful reads.   Sounds
> like you want it back for successful reads as well?

But the reason why loadend *and load* was removed from video do not
apply here. The reason there was that they never guarentee that the
whole video is downloaded such that it can be accessed without further
need for network access.

Additionally we should follow the intent of the Progress Events spec.

>> * I'm not sure i love the name 'fileData'. Maybe 'result' or simply
>> 'data' is better.
>>
>
> I'm happy to change it to a better name, but chose 'fileData' since in the
> original version of the draft, with asynchronous callbacks [3], we had an
> interface called FileData which represented the actual file data (in the
> present and current version of the editor's draft --
> http://dev.w3.org/2006/webapi/FileAPI/ -- FileData is called Blob) .

But that FileData represented the actual data in the file. .fileData
can be a data-uri or a string of text, neither of which is exactly the
data in the file.

> Of the
> two names you suggest,  do you feel strongly about one over the others?
> I'm not sure I love 'result' (it isn't intuitive as a response to a read),
> and 'data' is used in other contexts on the platform and so may be
> confusing.  If you feel strongly (stronger than a 'maybe' ;-) ) about a
> different name, I'm happy to change it.

I don't feel that strongly no. But i think 'result' the the most
correct name that I can think of.

>> * Whatever the name, I don't see why 'fileData' should only be
>> readable while an event is being fired. That seems unnecessarily
>> complicated, doesn't match XHR and seems less useful.
>>
>
> Nothing in the present draft prohibits that -- I only left an editor's note
> as an open question.  I agree with you about the desired behavior,  and so
> I'll remove the editor's note.

Ah, ok. There was also some confusing wording in the definition of the
attribute:

"On getting, if progress  events are queued for dispatch while
processing the readAsText read method, this attibute SHOULD return
partial file data in the format specified by the encoding
determination)"

However it should contain the data read so far even if there currently
aren't any progress events queued for dispatch. I.e. if a progress
event was just dispatched and no more data has been read so far, then
.fileData should still contain the same value as when the last
progress event was dispatched.

>> * I think someone had brought up a good argument for *not* throwing
>> when slice is called with start+offset > size. One of the main use
>> cases for slice is to slice up a file in several chunks when sending
>> with XHR. When that is done it's easy to end up with rounding errors
>> resulting in a slightly to large length being requested. In this case
>> it makes sense to just clamp to size rather than throwing an error.
>>
>
> OK -- sounds like slice should NOT throw an INDEX_SIZE_ERR at all, and only
> clamp on size?

Yeah, I think so. Except if the 'start' attribute is bigger then size.
Though possibly we could even then clamp to a zero-sized Blob. I don't
really feel strongly.

/ Jonas

[Jonas Sicking-2]

On Tue, Oct 27, 2009 at 12:36 AM, Ian Hickson <ian@...> wrote:
>> 3. The event model resembles that of XHR2, with a few differences.
>> Notably, the APIs differ in their use of the 'loadend' ProgressEvent.
>
> I think this spec needs examples. I think the examples would show that the
> current design requires far too many lines of code to do something that
> really should only need one or two statements.
>
> (I think XHR is a very poor model to follow.)

I was as surprised as you, but the feedback we consistently received,
both here and when talking directly to developers, was that using an
events-based model was preferable to using callbacks. We also received
the feedback that following XHR was good because authors were used to
this model.

I agree that especially the common simple use case results in more
lines of code, but it doesn't need to be as complicated as the example
in the beginning of the spec:

r = new FileReader;
r.readAsText(file);
r.onload = fileIsRead;

>> 4. A suggestion to *not* have a separate scheme ("filedata:") in lieu of
>> urn:uuid:<uuid>[2] has been the basis of a rewrite of that feature in
>> this version of the specification.
>
> I would like to see implementation feedback on this. I don't understand
> why we would want to assign semantics to urn:uuid: URLs that are so
> specific -- that seems completely wrong. It also seems really awkward from
> an implementation perspective to forgo the normal extension mechanism
> (schemes) and have implementations give special (and non-trivial)
> semantics to a subset of another scheme. Why are we doing this?

I'd like to hear implementation feedback here too. I'm especially
worried that implementations might not be able to use the urn scheme
due to limitations in the network stacks they are using.

But like Arun, I suspect that this feature is the most controversial
in the spec. Apple expressed concern about having a string represent a
handle to a resource, and when we talked to Microsoft they briefly
mentioned that they has concerns about this feature too, though I
don't know specifically what their concerns were.

I don't think we are assigning specific semantics to another scheme
that aren't already there. All we're saying is that urn:uuid
represents a specific chunk of data with a specific mimetype. This
seems like something that's already there with urn:uuid.

Arguably the status codes is something that urn:uuid doesn't already
have. Arun mentioned that we could possibly get rid of that.

/ Jonas

[Ian Hickson]

On Tue, 27 Oct 2009, Jonas Sicking wrote:
>
> All we're saying is that urn:uuid represents a specific chunk of data
> with a specific mimetype. This seems like something that's already there
> with urn:uuid.

We're also saying that urn:uuid: has special semantics in the same-origin
model, and that it has an expiration model.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Jonas Sicking-2]

On Tue, Oct 27, 2009 at 2:49 PM, Ian Hickson <ian@...> wrote:
> On Tue, 27 Oct 2009, Jonas Sicking wrote:
>>
>> All we're saying is that urn:uuid represents a specific chunk of data
>> with a specific mimetype. This seems like something that's already there
>> with urn:uuid.
>
> We're also saying that urn:uuid: has special semantics in the same-origin
> model, and that it has an expiration model.

The expiration model is just that when the Document goes away the
urn:uuid is changed to no longer represent that chunk of data.

The origin is something that at least in gecko we build on top of the
URI, i.e. the URI itself doesn't contain any origin information. If
you consider it to be part of the URI, then why wouldn't each
urn:uuids already have an origin?

/ Jonas

[Ian Hickson]

On Tue, 27 Oct 2009, Jonas Sicking wrote:

> On Tue, Oct 27, 2009 at 2:49 PM, Ian Hickson <ian@...> wrote:
> > On Tue, 27 Oct 2009, Jonas Sicking wrote:
> >>
> >> All we're saying is that urn:uuid represents a specific chunk of data
> >> with a specific mimetype. This seems like something that's already there
> >> with urn:uuid.
> >
> > We're also saying that urn:uuid: has special semantics in the same-origin
> > model, and that it has an expiration model.
>
> The expiration model is just that when the Document goes away the
> urn:uuid is changed to no longer represent that chunk of data.
>
> The origin is something that at least in gecko we build on top of the
> URI, i.e. the URI itself doesn't contain any origin information. If you
> consider it to be part of the URI, then why wouldn't each urn:uuids
> already have an origin?

I just mean that if someone else decides that they are going to resolve
urn:uuid:s in some way or other, the origin model they would use will
almost certainly be quite different to the origin model we are using here.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Jonas Sicking-2]

On Tue, Oct 27, 2009 at 3:26 PM, Ian Hickson <ian@...> wrote:

> On Tue, 27 Oct 2009, Jonas Sicking wrote:
>> On Tue, Oct 27, 2009 at 2:49 PM, Ian Hickson <ian@...> wrote:
>> > On Tue, 27 Oct 2009, Jonas Sicking wrote:
>> >>
>> >> All we're saying is that urn:uuid represents a specific chunk of data
>> >> with a specific mimetype. This seems like something that's already there
>> >> with urn:uuid.
>> >
>> > We're also saying that urn:uuid: has special semantics in the same-origin
>> > model, and that it has an expiration model.
>>
>> The expiration model is just that when the Document goes away the
>> urn:uuid is changed to no longer represent that chunk of data.
>>
>> The origin is something that at least in gecko we build on top of the
>> URI, i.e. the URI itself doesn't contain any origin information. If you
>> consider it to be part of the URI, then why wouldn't each urn:uuids
>> already have an origin?
>
> I just mean that if someone else decides that they are going to resolve
> urn:uuid:s in some way or other, the origin model they would use will
> almost certainly be quite different to the origin model we are using here.

This doesn't seem to be a problem as long as the two specs don't
mandate the exact same uuids.

But again, I'd like feedback from other implementations with different
network stacks.

/ Jonas

[Arun Ranganathan-4]

Ian Hickson wrote:

> On Tue, 27 Oct 2009, Jonas Sicking wrote:
>  
>> On Tue, Oct 27, 2009 at 2:49 PM, Ian Hickson <ian@...> wrote:
>>    
>>> On Tue, 27 Oct 2009, Jonas Sicking wrote:
>>>      
>>>> All we're saying is that urn:uuid represents a specific chunk of data
>>>> with a specific mimetype. This seems like something that's already there
>>>> with urn:uuid.
>>>>        
>>> We're also saying that urn:uuid: has special semantics in the same-origin
>>> model, and that it has an expiration model.
>>>      
>> The expiration model is just that when the Document goes away the
>> urn:uuid is changed to no longer represent that chunk of data.
>>
>> The origin is something that at least in gecko we build on top of the
>> URI, i.e. the URI itself doesn't contain any origin information. If you
>> consider it to be part of the URI, then why wouldn't each urn:uuids
>> already have an origin?
>>    
>
> I just mean that if someone else decides that they are going to resolve
> urn:uuid:s in some way or other, the origin model they would use will
> almost certainly be quite different to the origin model we are using here.
>  

Yes; that is true, and is a concern.  However, my reading of:
http://www.ietf.org/rfc/rfc4122 (which describes urn:uuid) suggest that
namespace resolution for UUIDs, coupled with general stipulations for
namespace resolution, make this a manageable problem.

 From RFC4122, Section 3:

"   Process for identifier resolution:      Since UUIDs are not globally
resolvable, this is not applicable."

Moreover, in http://www.ietf.org/rfc/rfc2141.txt (which describes URN
syntax), we find that:

"... Namespace registration must include guidance on how to determine
functional equivalence for that namespace, i.e. when two URNs are
identical within a namespace."

We're unlikely to have *identical URNs* in the uuid namespace.  One
reason I chose UUID is because the "identical URN" problem is unlikely.

That leaves the problem of persistence (which is also a stipulation on
URNs) but I think that we are entitled to define persistence in terms of
the Document's persistence.

I'd like to hear from implementors, and of course those that disagree
with my reading of these specifications.  I'm amenable to dropping the
HTTP responses if that helps.

-- A*

[Dominique Hazael-Massieux-2]

Le lundi 26 octobre 2009 à 05:24 -0700, Arun Ranganathan a écrit :
> The latest revision of the FileAPI editor's draft is available here:
> http://dev.w3.org/2006/webapi/FileAPI/

The WebIDL checker identifies a couple of simple bugs in the draft:
http://www.w3.org/2009/07/webidl-check?doc=http%3A%2F%2Fdev.w3.org%
2F2006%2Fwebapi%2FFileAPI%2F&output=html
(a missing “;” and an erroneous usage of “attribute” inside an
Exception).

Dom

[Arun Ranganathan-4]

Dominique Hazael-Massieux wrote:

> Le lundi 26 octobre 2009 à 05:24 -0700, Arun Ranganathan a écrit :
>  
>> The latest revision of the FileAPI editor's draft is available here:
>> http://dev.w3.org/2006/webapi/FileAPI/
>>    
>
> The WebIDL checker identifies a couple of simple bugs in the draft:
> http://www.w3.org/2009/07/webidl-check?doc=http%3A%2F%2Fdev.w3.org%
> 2F2006%2Fwebapi%2FFileAPI%2F&output=html
> (a missing “;” and an erroneous usage of “attribute” inside an
> Exception).
>
> Dom
>
>  

Fixed!

(This is a very useful tool :-) )

-- A*

[Arun Ranganathan-4]

Jonas,

>> When loadend was removed from media elements [2] I wished to determine
>> whether it was event overkill to also fire at successful reads.   Sounds
>> like you want it back for successful reads as well?
>>    
>
> But the reason why loadend *and load* was removed from video do not
> apply here. The reason there was that they never guarentee that the
> whole video is downloaded such that it can be accessed without further
> need for network access.
>
> Additionally we should follow the intent of the Progress Events spec.
>  

Done.

(I was simply wrong about loadend, and citing media elements wasn't
helpful; I've changed the spec. to show that loadend should be fired,
and it now matches the behavior of the XHR2 editor's draft.)

>>  Of the
>> two names you suggest,  do you feel strongly about one over the others?
>> I'm not sure I love 'result' (it isn't intuitive as a response to a read),
>> and 'data' is used in other contexts on the platform and so may be
>> confusing.  If you feel strongly (stronger than a 'maybe' ;-) ) about a
>> different name, I'm happy to change it.
>>    
>
> I don't feel that strongly no. But i think 'result' the the most
> correct name that I can think of.
>
>  

Done.

*grumble grumble OK Jonas, in the interest of not bike shedding I've
renamed fileData to result*

>
> Ah, ok. There was also some confusing wording in the definition of the
> attribute:
>
> "On getting, if progress  events are queued for dispatch while
> processing the readAsText read method, this attibute SHOULD return
> partial file data in the format specified by the encoding
> determination)"
>
> However it should contain the data read so far even if there currently
> aren't any progress events queued for dispatch. I.e. if a progress
> event was just dispatched and no more data has been read so far, then
> .fileData should still contain the same value as when the last
> progress event was dispatched.
>
>  

Fixed; this isn't harnessed to queuing ProgressEvents for dispatch anymore.

>>> * I think someone had brought up a good argument for *not* throwing
>>> when slice is called with start+offset > size. One of the main use
>>> cases for slice is to slice up a file in several chunks when sending
>>> with XHR. When that is done it's easy to end up with rounding errors
>>> resulting in a slightly to large length being requested. In this case
>>> it makes sense to just clamp to size rather than throwing an error.
>>>
>>>      
>> OK -- sounds like slice should NOT throw an INDEX_SIZE_ERR at all, and only
>> clamp on size?
>>    
>
> Yeah, I think so. Except if the 'start' attribute is bigger then size.
> Though possibly we could even then clamp to a zero-sized Blob. I don't
> really feel strongly.
>
>  

Fixed

(I don't feel strongly about whether to throw or not, so I changed it to
*clamp.*  It may offer conveniences to NOT throw, but I'd like to hear
from others).

http://dev.w3.org/2006/webapi/FileAPI/

-- A*

[Julian Reschke]

Arun Ranganathan wrote:
> The latest revision of the FileAPI editor's draft is available here:
>
> http://dev.w3.org/2006/webapi/FileAPI/
> ...
>
> 4. A suggestion to *not* have a separate scheme ("filedata:") in lieu of
> urn:uuid:<uuid>[2] has been the basis of a rewrite of that feature in
> this version of the specification.
> ...

Is there a particular reason why a specific URI scheme needs to be
called out at all?

(there are other schemes that may be more flexible, for instance because
they allow using a UUID/String pair for identification).

Best regards, Julian

[Adrian Bateman]

On Tuesday, October 27, 2009 2:35 PM, Jonas Sicking wrote:
> On Tue, Oct 27, 2009 at 12:36 AM, Ian Hickson <ian@...> wrote:
> > I would like to see implementation feedback on this. I don't
> > understand
> > why we would want to assign semantics to urn:uuid: URLs that are so
> > specific -- that seems completely wrong. It also seems really awkward
> > from
> > an implementation perspective to forgo the normal extension mechanism
> > (schemes) and have implementations give special (and non-trivial)
> > semantics to a subset of another scheme. Why are we doing this?

> But like Arun, I suspect that this feature is the most controversial
> in the spec. Apple expressed concern about having a string represent a
> handle to a resource, and when we talked to Microsoft they briefly
> mentioned that they has concerns about this feature too, though I
> don't know specifically what their concerns were.

The main concern I had was whether the URN feature was a must have for v1 given Arun's desire that this be the simplest spec that we could then build on later. Implementing a new protocol handler is more complex than just supporting the API part, for us anyway.

I am also concerned about introducing new origin semantics - in the past this has been a source of security bugs and so I question whether we need to rush into this part (I accept the use case is valuable but I'm not sure it is initially essential).

Cheers,

Adrian.

[Jonas Sicking-2]

On Mon, Nov 2, 2009 at 12:25 PM, Adrian Bateman <adrianba@...> wrote:

> On Tuesday, October 27, 2009 2:35 PM, Jonas Sicking wrote:
>> On Tue, Oct 27, 2009 at 12:36 AM, Ian Hickson <ian@...> wrote:
>> > I would like to see implementation feedback on this. I don't
>> > understand
>> > why we would want to assign semantics to urn:uuid: URLs that are so
>> > specific -- that seems completely wrong. It also seems really awkward
>> > from
>> > an implementation perspective to forgo the normal extension mechanism
>> > (schemes) and have implementations give special (and non-trivial)
>> > semantics to a subset of another scheme. Why are we doing this?
>
>> But like Arun, I suspect that this feature is the most controversial
>> in the spec. Apple expressed concern about having a string represent a
>> handle to a resource, and when we talked to Microsoft they briefly
>> mentioned that they has concerns about this feature too, though I
>> don't know specifically what their concerns were.
>
> The main concern I had was whether the URN feature was a must have for v1 given Arun's desire that this be the simplest spec that we could then build on later. Implementing a new protocol handler is more complex than just supporting the API part, for us anyway.
>
> I am also concerned about introducing new origin semantics - in the past this has been a source of security bugs and so I question whether we need to rush into this part (I accept the use case is valuable but I'm not sure it is initially essential).

I'd really like to try to keep it in version 1. One of the use cases
we hear most often for this API is for uploading images. For example
to photo management sites like Flickr, but also for profile pictures
on sites like twitter. In both these cases it's possible to use
data-uris, but that will most likely result in the several copies of a
several-MB-sized data-uris living in memory. I think the situation
might be even worse in IE which if recall correctly there's some
fairly low limits on how big data-uris can be (is this correct?).

Are you concerned about security bugs in the feature design or in the
implementation?

/ Jonas

[Adrian Bateman]

On Monday, November 02, 2009 10:12 PM, Jonas Sicking wrote:

> On Mon, Nov 2, 2009 at 12:25 PM, Adrian Bateman
> <adrianba@...> wrote:
> > On Tuesday, October 27, 2009 2:35 PM, Jonas Sicking wrote:
> >> But like Arun, I suspect that this feature is the most controversial
> >> in the spec. Apple expressed concern about having a string represent
> >> a
> >> handle to a resource, and when we talked to Microsoft they briefly
> >> mentioned that they has concerns about this feature too, though I
> >> don't know specifically what their concerns were.
> >
> > The main concern I had was whether the URN feature was a must have
> > for v1 given Arun's desire that this be the simplest spec that we could
> > then build on later. Implementing a new protocol handler is more
> > complex than just supporting the API part, for us anyway.
> >
> > I am also concerned about introducing new origin semantics - in the
> > past this has been a source of security bugs and so I question whether
> > we need to rush into this part (I accept the use case is valuable but
> > I'm not sure it is initially essential).
>
> I'd really like to try to keep it in version 1. One of the use cases
> we hear most often for this API is for uploading images. For example
> to photo management sites like Flickr, but also for profile pictures
> on sites like twitter. In both these cases it's possible to use
> data-uris, but that will most likely result in the several copies of a
> several-MB-sized data-uris living in memory. I think the situation
> might be even worse in IE which if recall correctly there's some
> fairly low limits on how big data-uris can be (is this correct?).

There is a limit on the size of data-uris in IE8 (32K I think). I expect addressing this will be a higher priority than a new handler but I agree that copying around large strings is problematic.

> Are you concerned about security bugs in the feature design or in the
> implementation?

Mostly in the implementation - it increases the surface area to be concerned about and there might be a different approach.

This isn't something I feel really strongly about. I imagine that when we look at implementing this we will start with just the API part and look at the URN handling separately.

Cheers,

Adrian.

[Arun Ranganathan-4]

Adrian Bateman wrote:

> On Monday, November 02, 2009 10:12 PM, Jonas Sicking wrote:
>  
>> On Mon, Nov 2, 2009 at 12:25 PM, Adrian Bateman
>> <adrianba@...> wrote:
>>    
>>> On Tuesday, October 27, 2009 2:35 PM, Jonas Sicking wrote:
>>>      
>>>> But like Arun, I suspect that this feature is the most controversial
>>>> in the spec. Apple expressed concern about having a string represent
>>>> a
>>>> handle to a resource, and when we talked to Microsoft they briefly
>>>> mentioned that they has concerns about this feature too, though I
>>>> don't know specifically what their concerns were.
>>>>        
>>> The main concern I had was whether the URN feature was a must have
>>> for v1 given Arun's desire that this be the simplest spec that we could
>>> then build on later. Implementing a new protocol handler is more
>>> complex than just supporting the API part, for us anyway.
>>>
>>> I am also concerned about introducing new origin semantics - in the
>>> past this has been a source of security bugs and so I question whether
>>> we need to rush into this part (I accept the use case is valuable but
>>> I'm not sure it is initially essential).
>>>      
>> I'd really like to try to keep it in version 1. One of the use cases
>> we hear most often for this API is for uploading images. For example
>> to photo management sites like Flickr, but also for profile pictures
>> on sites like twitter. In both these cases it's possible to use
>> data-uris, but that will most likely result in the several copies of a
>> several-MB-sized data-uris living in memory. I think the situation
>> might be even worse in IE which if recall correctly there's some
>> fairly low limits on how big data-uris can be (is this correct?).
>>    
>
> There is a limit on the size of data-uris in IE8 (32K I think). I expect addressing this will be a higher priority than a new handler but I agree that copying around large strings is problematic.
>  

FWIW, the specification makes a provision for URL length limitations in
certain user agents, so that a file (as a Data URL) that exceeds a
URL-length limit will force an ENCODING_ERR when the readAsDataURL
method is called on a FileReader object.
>  
>> Are you concerned about security bugs in the feature design or in the
>> implementation?
>>    
>
> Mostly in the implementation - it increases the surface area to be concerned about and there might be a different approach.
>  

This feedback as a potential implementor is important :-)

1. Can you give us an example of an exploit, or expand on your concerns?

2. From an implementation perspective, do you care whether we define a
scheme (such as filedata:) or reuse something like urn:uuid:[UUID] ? Are
there any barriers with respect to either one?

> This isn't something I feel really strongly about. I imagine that when we look at implementing this we will start with just the API part and look at the URN handling separately.
>
>  

This is in fact pretty much the approach we have taken with Firefox 3.6
(currently in beta).

-- A*