Re: [File API] feedback on August 1/5 draft

On Thu, Aug 6, 2009 at 11:29 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Thu, Aug 6, 2009 at 4:04 AM, Anne van Kesteren<annevk@opera.com> wrote:
> > Thanks for the update to the draft! Below some feedback:
> >
> > In the table of contents the link to the filedata URL scheme is broken.
> >
> >
> > The Web IDL syntax needs to be updated. E.g. FileList can be simply
> described as
> >
> >  typedef sequence<any> FileList;
>
> You mean:
>
> typedef sequence<File> FileList;
>
> right?
>
> > I have not received any feedback on my comments as to why getAsDataURL is
> actually needed. I still think it should be dropped.
>
> Given that the filedata url is very limited in time, getAsDataURL
> still seems useful IMHO.
>
> > I think getAsURL() should become an attribute instead. E.g.
> >
> >  readonly attribute DOMString localURL;
> >
> > Since it is just a reference there is no need this needs to be
> asynchronous and there is also no need for it to be method.
>
> Agreed.


The draft says a new UUID should be 'coined' for each method invocation.
(Why is that?) Given the coinage of a new url on each access, accessing it
thru an attribute feels a little odd.


>
>
> > The constants of FileError need to be actually placed on the FileError
> object and renumbered as to make sense. They are not DOM exceptions so it
> does not make sense to align with that in any way.
>
> It seems useful to use the same code for people that want to display
> error messages to the user, this way you can either pass the value in
> the DOM event or from an exception to the same function.
>
> I also can't see a downside to aligning the values?
>
> But I don't feel strongly here.
>
> > Last time I also made comments regarding the details of discovering the
> encoding of a file etc. Those still seem to apply.
>
> Got a pointer to the actual question?
>
> / Jonas
>
>