Re: [File API] feedback on August 1/5 draft
Anne van Kesteren wrote: On Sat, 22 Aug 2009 11:30:18 +0200, Simon Pieters sim...@opera.com wrote: On Wed, 12 Aug 2009 17:22:53 +0200, Arun Ranganathan a...@mozilla.com wrote: http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html Maybe the attribute should be called URL for consistency with HTMLDocument.URL? And also WebSocket.URL and EventSource.URL. I'll change this to be consistent. -- A*
Re: [File API] feedback on August 1/5 draft
On Thu, 13 Aug 2009 02:02:30 +0200, Arun Ranganathan a...@mozilla.com wrote: Anne van Kesteren wrote: I think [FileData.url] also should only be available on File. This would probably be fine, although for filedata: URLs, we don't *need* a mediaType (we could just define octet stream or something on slice'd FileData objects). I'm ok with moving it, thought. The reason I think it makes sense to move it is that all URL consumers expect a full file. Not strongly no, but if we just want to reuse DOMException here isn't that what we should do rather than have FileException? Possibly, but I was thinking of having slice throw exception.SLICE_ERR if the range mathematics is wrong. It probably won't need to throw for any other reasons. The problem I have with the design is that it is somewhat compatible with DOMException, but not necessarily so with future extensions to DOMException. Either we should coordinate the two or make them separate. -- Anne van Kesteren http://annevankesteren.nl/
Re: [File API] feedback on August 1/5 draft
Latest draft is: http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html Anne van Kesteren 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. Fixed. The Web IDL syntax needs to be updated. E.g. FileList can be simply described as typedef sequenceany FileList; Done I have not received any feedback on my comments as to why getAsDataURL is actually needed. I still think it should be dropped. The rationale submitted by Jonas seems to be sufficient. [1] 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. Done. 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. They are placed on the FileError object now, but have not been renumbered. Additionally, slice is now spec'd to throw a FileException. I'm not tightly wed to keeping the numbers the same as DOMException, but honestly reusing SECURITY_ERR and NOT_FOUND_ERR from DOMException seems desirable. SECURITY_ERR is used by XHR as well, so keeping these consistent (since File API will probably used in conjunction with XHR) also seems desirable. I also agree that simply using a meaningful constant name is also useful, but kept the numbers the same for consistency. Aside from numbering, I don't think there's a big difference between FileError / FileException and SQLError/SQLException (or MediaError, etc.). Do you feel very strongly about renumbering? The filedata URI scheme should allow the use of fragment identifiers on the resource. Also, I think we should drop the // from the scheme. I do not see why that is needed here. I've dropped the //, but haven't spec'd the scheme to allow fragment identifiers on the resource. Could give me a use case? Last time I also made comments regarding the details of discovering the encoding of a file etc. Those still seem to apply. Anne, I thought that even my past draft addressed most of them, with one exception! These comments seem to have been: * I assume it is meant that if the encoding parameter is not provided UTF-8 is used for decoding the file. I think that should be made more clear. -- It is clear, but only iff. implementations cannot determine a decoding to use. You've said that the left to implementations part is unacceptable, but that actually seems desirable, and they MUST use UTF-8 if they cannot determine the decoding. Since they must fall back on UTF-8, is this not sufficient? * However, wouldn't it be better to use e.g. XML rules for XML files and HTML rules for HTML files? -- The File interface has a mediaType attribute. I reasoned that by determining the mediaType, callers can determine which rules to use, or at least determine whether they can use the filedata: scheme to surface the content, etc. Would you like me to make explicit statements about XML/HTML, or is this sufficient? * It would also make sense to observe any BOM the file might have and maybe information provided by the platform? Rules similar to how responseText for XMLHttpRequest is computed could be used here I think. -- I specify that user agents can make a determination, and assumed this as the case. I can make this more explicit in a subsequent draft, and look at responseText rules. This is probably the only thing not fully addressed, unless you have further nits on how I've addressed your other nits. * It should also define how to deal with bytes it cannot decode with the given encoding. E.g. replace them with U+FFFD as done elsewhere in the Platform. -- Done. -- A* [1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0511.html
Re: [File API] feedback on August 1/5 draft
Michael Nordman wrote: 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. This should have been an editor's note, and not a part of the spec. text. The unique and hard to guess nature of the URL is covered by both lifetime and origin requirements, and I think the new coinage requirement was overkill without payoff :-) I've eliminated that requirement, and thus we now have filedata.url which returns a filedata: scheme URL. http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html -- A*
Re: [File API] feedback on August 1/5 draft
Anne van Kesteren wrote: On Wed, 12 Aug 2009 17:13:57 +0200, Arun Ranganathan a...@mozilla.com wrote: Latest draft is: http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html Thanks Arun! Anne van Kesteren wrote: I have not received any feedback on my comments as to why getAsDataURL is actually needed. I still think it should be dropped. The rationale submitted by Jonas seems to be sufficient. [1] Yeah. Come to think of it though, it needs to be specified on File rather than FileData. For a data URL you need the media type and that is only available from File (and does not make sense for all of FileData). I agree with this. 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. Done. I think this also should only be available on File. This would probably be fine, although for filedata: URLs, we don't *need* a mediaType (we could just define octet stream or something on slice'd FileData objects). I'm ok with moving it, thought. Not strongly no, but if we just want to reuse DOMException here isn't that what we should do rather than have FileException? Possibly, but I was thinking of having slice throw exception.SLICE_ERR if the range mathematics is wrong. It probably won't need to throw for any other reasons. Also, CANCEL_ERR should be renamed to ABORT_ERR to be in line with XMLHttpRequest / Web DOM Core. Agreed! The filedata URI scheme should allow the use of fragment identifiers on the resource. Also, I think we should drop the // from the scheme. I do not see why that is needed here. I've dropped the //, but haven't spec'd the scheme to allow fragment identifiers on the resource. Could give me a use case? If you can store and open documents I imagine you can view them inside iframe as well and it would make sense if you could set fragment identifiers of such a resource to scroll within them. SVG couples special semantics to the fragment identifier for image/svg+xml resources. If the user selects an SVG resource an application might want to use such fragment identifiers. Agreed, I'll add this to my ToDos for FileAPI. Yeah, though I'd replace encoding is in UTF-8 with encoding is UTF-8. OK I think it should be explicit if we want implementations to use XML/HTML rules to determine the character encoding when the media type of the file matches. OK By the way, you have written mediatype rather than media type twice. I'll fix this. -- A*
Re: [File API] feedback on August 1/5 draft
On Sat, Aug 8, 2009 at 6:25 AM, Anne van Kesterenann...@opera.com wrote:
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);
}
If instead of errorNumber you passed the object you could do things like
if (obj.SECURITY_ERR == obj.code) {
...
}
which is what I meant.
This seems like a very strange way of sending strings but sending them
encoded as a number and a enumerated string-bundle. I.e. we provide
the author with a code number, but then ask him/her to compare it
against some other numerical values accessed by name, rather than
simply make the number useful. In addition, it means that you can't
use switch statements or hash lookups to implement
getLocalizedErrorMessage above.
Also, I'll note that you carefully snipped my inconsistency argument!
Sorry, my mistake. I do agree that the values should be moved into the
interface. I don't even think it's proper WebIDL as it is now.
/ Jonas
Re: [File API] feedback on August 1/5 draft
On Thu, Aug 6, 2009 at 11:29 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Aug 6, 2009 at 4:04 AM, Anne van Kesterenann...@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 sequenceany FileList; You mean: typedef sequenceFile 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
Re: [File API] feedback on August 1/5 draft
On Fri, Aug 7, 2009 at 3:21 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Aug 7, 2009 at 12:23 PM, Michael Nordmanmicha...@google.com wrote: 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. I think we should removed that requirement though. I'd be in favor of removing that requirement too. (Unless there is an actual reason for it to start with? The draft was very expicit about calling for a new guid on each access, i have no clue why.) / Jonas
Re: [File API] feedback on August 1/5 draft
On Thu, Aug 6, 2009 at 4:04 AM, Anne van Kesterenann...@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 sequenceany FileList; You mean: typedef sequenceFile 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 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
Re: [File API] feedback on August 1/5 draft
I meant File rather than any, yes. Oops. Also: On Thu, 06 Aug 2009 20:29:37 +0200, Jonas Sicking jo...@sicking.cc wrote: On Thu, Aug 6, 2009 at 4:04 AM, Anne van Kesterenann...@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. And how limited is it exactly? 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. 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 also can't see a downside to aligning the values? What if we introduce a new DOM Exception. Will it have to skip these numbers? Apart from that, this design is not consistent with similar APIs: MediaError and SQLError. 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. -- Anne van Kesteren http://annevankesteren.nl/
Re: [File API] feedback on August 1/5 draft
On Thu, Aug 6, 2009 at 11:42 AM, Anne van Kesterenann...@opera.com wrote:
I meant File rather than any, yes. Oops. Also:
On Thu, 06 Aug 2009 20:29:37 +0200, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Aug 6, 2009 at 4:04 AM, Anne van Kesterenann...@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
