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

On Thu, Aug 6, 2009 at 11:42 AM, Anne van Kesteren<annevk@opera.com> wrote:
> I meant File rather than any, yes. Oops. Also:
>
> On Thu, 06 Aug 2009 20:29:37 +0200, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Thu, Aug 6, 2009 at 4:04 AM, Anne van Kesteren<annevk@opera.com> wrote:
>>>
>>> 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.
>
> What is the use case? If the use case is storage I think we should address
> that issue specifically.

For example an web HTML editor. The editor lets you wysiwyg edit the
page as well as drop in images. Dropping in images creates a <img
src="uri-here" alt="..."> element. The edited page can then be saved
in localStorage, sent to the server using XHR, or posted to a parent
iframe using postMessage.

It's possible, but very clunky, to always send images separately and
then refresh the inline uris any time the page is to be displayed.

> And how limited is it exactly?

It's the lifetime of the Document to which the URI "belongs" to. Details at [1]

[1] http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html#lifetime

> Ian was also suggesting you could increase
> the duration somehow in his original proposal for the new URL scheme. I
> haven't seen any email addressing that point yet.

I haven't seen a concrete proposal for the "somehow" yet so I can't
really comment on it.

>>> 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.
>
> If you use the same constant name you can still do that.

I don't understand. The use case is:

A page has a function to deal with displaying error messages to the
user. The function looks something like:

function displayError(errorNumber) {
  var errorString = getLocalizedErrorMessage(errorNumber);
  document.getElementById("errorMessage").nodeValue = errorString;
  errorDialog.classList.add("displayed");
  cancelTimeout(gErrorUITimeout);
  gErrorUITimeout = setTimeout(hideError, 5000);
}

When an error occurs, this function is called like:

try {
  doStuffHere();
} catch (ex) {
  displayError(ex.code);
}

It would seem useful if the page could do the same for errors received
through events. Such as

someFile.getAsText(function(str, err) {
  if (err) {
    displayError(err);
    return;
  }

  doStuffHereToo();
});

>>> 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?
>
> http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1105.html
> second bullet point under getAsText(). In particular the way to derive the
> encoding is completely left up to the user agent. I do not think that is
> acceptable as the bug reports we end up getting from that will be very
> confusing and very hard to figure out. Effectively it will mean we'd have to
> reverse engineer the market leader.

For local files it doesn't seem like there would be interoperability
issues here. You won't run into the situation where one website works
in one browser, but not another. Additionally I think we want to give
UAs freedom to use information such as the common encodings for the
locale of the OS that the user is using.

It is more of a problem if we start introducing APIs that allow you to
create File objects. For example creating a File from a string or from
an ImageData. For these APIs we could define what the encoding of the
File is and define that that encoding is always used when getAsText is
called.

/ Jonas

Received on Friday, 7 August 2009 00:20:21 UTC