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.   `._.-(,_..'--(,_..'`-.;.'

Reply via email to