Suggestion (redirection)
I'm implementing the WebSocket my company's servers, and would arrange an OPCODE which means redirection in my case I set the code %x6 for this function.
HTML5 Filesystem API feedback
Hello public-webapps, I've spent a bit of time with the filesystem API recently, building out a set of common file dialogs (open, save-as, etc) for ChromeOS. We have a private API call to get access to a special filesystem that contains the user's downloads folder and the mounted external storage, but beyond that the dialogs use the standard filesystem API calls. The bulk of the code is here: http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/resources/file_manager/js/ I've run into a few awkward bits that I'd like to bring up here to see what everyone else thinks. * The async API is really awkward when you want to resolve multiple entries. I have a case where I'd like to resolve a list of directories and then do something when that completes. It would be helpful if the DirectoryEntry class had a getDirectories() method. I've built my own in file_manager/js/util.js in the function called util.getDirectories. * That leads to a desire to get entries in the general sense. In my case I knew ahead of time that I had a list of directories. If I didn't know whether I had been handed directories or files, the code would get pretty hairy. So in addition to getDirectories, a getEntries method (and getEntry, too) would be super useful. * Another helper I found useful was util.forEachDirEntry from the same file previously mentioned. This function invokes a callback once for each entry in a directory. This saves the caller from having to create the reader and walk the results array during the callback. It makes client code significantly more readable. I'd love to see DirectoryEntry.forEach(...). * The FileError object is a bit awkward to work with. I found that I frequently had every reason to expect my calls to succeed (because they were a follow-on to something that already succeeded), but I wanted to log the failure reason in the event they didn't. The code online suggests a switch/case statement to turn error codes into mnemonic strings. This requires a hardcoded list of all known errors, and a call out to this utility function every time you want to display the error reason in a readable way. I suggest adding the mnemonic string as a property of FileError, and displaying it as part of the toString. (See util.getFileErrorMnemonic() and util.installFileErrorToString() for example implementations.) Rob.
Re: Suggestion (redirection)
Feedback about the WebSocket protocol should be sent to the IETF HyBi working group: https://www.ietf.org/mailman/listinfo/hybi Adam On Wed, Apr 13, 2011 at 7:54 AM, Everton Sales everton.sales.bra...@gmail.com wrote: I'm implementing the WebSocket my company's servers, and would arrange an OPCODE which means redirection in my case I set the code %x6 for this function.
Re: HTML5 Filesystem API feedback
Robert: First of all, thanks for the feedback. On Wed, Apr 13, 2011 at 1:35 PM, Robert Ginda rgi...@chromium.org wrote: Hello public-webapps, I've spent a bit of time with the filesystem API recently, building out a set of common file dialogs (open, save-as, etc) for ChromeOS. We have a private API call to get access to a special filesystem that contains the user's downloads folder and the mounted external storage, but beyond that the dialogs use the standard filesystem API calls. The bulk of the code is here: http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/resources/file_manager/js/ I've run into a few awkward bits that I'd like to bring up here to see what everyone else thinks. * The async API is really awkward when you want to resolve multiple entries. I have a case where I'd like to resolve a list of directories and then do something when that completes. It would be helpful if the DirectoryEntry class had a getDirectories() method. I've built my own in file_manager/js/util.js in the function called util.getDirectories. In general, I'm pretty happy to see this sort of thing. You may not like to hear this, but any problem that can just be solved by layering a small javascript library on top of this API is a problem we don't need to fix in the first pass of the API. We want it to start out powerful and simple, and eventually, if that library is something that absolutely everyone seems to need, we may want to incorporate it. So it is very helpful to see the kinds of libraries that get built on top, and thanks for sending the pointer, but I suggest we wait and see before making any changes. BTW, you can make your getDirectories method faster if you don't wait for a response before sending off the next query [assuming no memory constraints]. Just fire off all the requests in one go, then keep a countdown of responses in your callback-wrapper. When your countdown hits zero, fire the we're done signal. * That leads to a desire to get entries in the general sense. In my case I knew ahead of time that I had a list of directories. If I didn't know whether I had been handed directories or files, the code would get pretty hairy. So in addition to getDirectories, a getEntries method (and getEntry, too) would be super useful. This is a method that would look up, but not create, an Entry, given a path? Can you outline the circumstances in which you'd use this, but where you wouldn't want to list the whole parent directory? * Another helper I found useful was util.forEachDirEntry from the same file previously mentioned. This function invokes a callback once for each entry in a directory. This saves the caller from having to create the reader and walk the results array during the callback. It makes client code significantly more readable. I'd love to see DirectoryEntry.forEach(...). I can see the utility there pretty clearly. * The FileError object is a bit awkward to work with. I found that I frequently had every reason to expect my calls to succeed (because they were a follow-on to something that already succeeded), but I wanted to log the failure reason in the event they didn't. The code online suggests a switch/case statement to turn error codes into mnemonic strings. This requires a hardcoded list of all known errors, and a call out to this utility function every time you want to display the error reason in a readable way. I suggest adding the mnemonic string as a property of FileError, and displaying it as part of the toString. (See util.getFileErrorMnemonic() and util.installFileErrorToString() for example implementations.) Hmm...I'm not sure what other APIs usually do about this. As soon as you start adding strings that you intend to be human-readable, you start getting into all sorts of internationalization issues. Anyone? Eric
RE: [FileAPI] Result of calling MultipleReads on FileReader
On Tuesday, April 12, 2011 12:08 PM, Jonas Sicking wrote: FileReader is extremely similar to XMLHttpRequest. The main difference is in how you initiate the request (.open/.send vs. .readAsX). This similarity is even getting stronger now that XHR gets .result. So I think there are good reasons to sticking to XMLHttpRequest here too. Note that no error events are fired by XMLHttpRequest. Just an abort event. So error is still reserved for actual reading errors whereas abort will fire for script-initiated aborts. I agree that calling .readAsX multiple times could be an indication of developer bugs and as such could throw an exception. However I think given the precedence set by XMLHttpRequest it could just as well mean that a new resource is now the one that the author is interested in reading. With this in mind, I don't personally have a strong feeling either way between having to call abort() explicitly or having readAsXXX implicitly call abort(). I've discussed it with others at Microsoft this week and the consensus here is that the defensive exception is better and that developers should have to call abort() if they want to abandon the current operation. I think we could live with either but right now we're planning for throwing the exception. We'd like to make a decision one way or the other pretty soon. Cheers, Adrian.
Re: [FileAPI] Result of calling MultipleReads on FileReader
On 4/15/11 2:57 PM, Adrian Bateman wrote: On Tuesday, April 12, 2011 12:08 PM, Jonas Sicking wrote: FileReader is extremely similar to XMLHttpRequest. The main difference is in how you initiate the request (.open/.send vs. .readAsX). This similarity is even getting stronger now that XHR gets .result. So I think there are good reasons to sticking to XMLHttpRequest here too. Note that no error events are fired by XMLHttpRequest. Just an abort event. So error is still reserved for actual reading errors whereas abort will fire for script-initiated aborts. I agree that calling .readAsX multiple times could be an indication of developer bugs and as such could throw an exception. However I think given the precedence set by XMLHttpRequest it could just as well mean that a new resource is now the one that the author is interested in reading. With this in mind, I don't personally have a strong feeling either way between having to call abort() explicitly or having readAsXXX implicitly call abort(). I've discussed it with others at Microsoft this week and the consensus here is that the defensive exception is better and that developers should have to call abort() if they want to abandon the current operation. I think we could live with either but right now we're planning for throwing the exception. We'd like to make a decision one way or the other pretty soon. Adrian: I'm keen to have behavior similar to XHR, and not raise an exception in this case. From your note above, I'm gathering you can live with an XHR-style abort which FileReader can fire on readAsXXX calls that have been superseded. Eric: can you point out where you think FileReader explicitly deviates in style from XHR2? -- A*
RE: [FileAPI] Result of calling MultipleReads on FileReader
On Friday, April 15, 2011 12:16 PM, Arun Ranganathan wrote: On 4/15/11 2:57 PM, Adrian Bateman wrote: With this in mind, I don't personally have a strong feeling either way between having to call abort() explicitly or having readAsXXX implicitly call abort(). I've discussed it with others at Microsoft this week and the consensus here is that the defensive exception is better and that developers should have to call abort() if they want to abandon the current operation. I think we could live with either but right now we're planning for throwing the exception. We'd like to make a decision one way or the other pretty soon. Adrian: I'm keen to have behavior similar to XHR, and not raise an exception in this case. From your note above, I'm gathering you can live with an XHR-style abort which FileReader can fire on readAsXXX calls that have been superseded. Yes, we could live with it but the semantics are more complex. Is this the same as calling abort() then readAsXXX()? When does the abort event get queued? What will be the state of the reader at this point? Will loadend get fired? It needs careful speccing to make sure that the details are handled the same in different implementations. Adrian.
Re: HTML5 Filesystem API feedback
Hi Eric, Thanks for your reply, my comments are inline... On Fri, Apr 15, 2011 at 11:53 AM, Eric Uhrhane er...@google.com wrote: Robert: First of all, thanks for the feedback. On Wed, Apr 13, 2011 at 1:35 PM, Robert Ginda rgi...@chromium.org wrote: Hello public-webapps, I've spent a bit of time with the filesystem API recently, building out a set of common file dialogs (open, save-as, etc) for ChromeOS. We have a private API call to get access to a special filesystem that contains the user's downloads folder and the mounted external storage, but beyond that the dialogs use the standard filesystem API calls. The bulk of the code is here: http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/resources/file_manager/js/ I've run into a few awkward bits that I'd like to bring up here to see what everyone else thinks. * The async API is really awkward when you want to resolve multiple entries. I have a case where I'd like to resolve a list of directories and then do something when that completes. It would be helpful if the DirectoryEntry class had a getDirectories() method. I've built my own in file_manager/js/util.js in the function called util.getDirectories. In general, I'm pretty happy to see this sort of thing. You may not like to hear this, but any problem that can just be solved by layering a small javascript library on top of this API is a problem we don't need to fix in the first pass of the API. We want it to start out powerful and simple, and eventually, if that library is something that absolutely everyone seems to need, we may want to incorporate it. So it is very helpful to see the kinds of libraries that get built on top, and thanks for sending the pointer, but I suggest we wait and see before making any changes. Sure, I see your point. I just think this is such an obvious problem (introduced by the necessarily asynchronous nature of the API), that it would be nice to offer a solution up front. Anything that isn't in the first pass of the API is likely to stick around in shim libraries for a long long time. BTW, you can make your getDirectories method faster if you don't wait for a response before sending off the next query [assuming no memory constraints]. Just fire off all the requests in one go, then keep a countdown of responses in your callback-wrapper. When your countdown hits zero, fire the we're done signal. Yeah, I've actually used the countdown version of this pattern in another part of the code. I probably should have used it here too. FWIW, it gets a bit difficult if you care about getting called back in the correct order. * That leads to a desire to get entries in the general sense. In my case I knew ahead of time that I had a list of directories. If I didn't know whether I had been handed directories or files, the code would get pretty hairy. So in addition to getDirectories, a getEntries method (and getEntry, too) would be super useful. This is a method that would look up, but not create, an Entry, given a path? Can you outline the circumstances in which you'd use this, but where you wouldn't want to list the whole parent directory? Say you wanted to implement the shell builtin 'mv source ... target'. You can have an arbitrary number of source entries, each of which can be either a file or a directory, and can be located at an arbitrary depth in the filesystem. The target, as well, could be an existing file or directory. With the existing API, you would have to try each source first as one type (say, getFile), then if that fails (with a TYPE_MISMATCH_ERR), try again using the other getter. A generic getEntry() would make this considerably cleaner. * Another helper I found useful was util.forEachDirEntry from the same file previously mentioned. This function invokes a callback once for each entry in a directory. This saves the caller from having to create the reader and walk the results array during the callback. It makes client code significantly more readable. I'd love to see DirectoryEntry.forEach(...). I can see the utility there pretty clearly. * The FileError object is a bit awkward to work with. I found that I frequently had every reason to expect my calls to succeed (because they were a follow-on to something that already succeeded), but I wanted to log the failure reason in the event they didn't. The code online suggests a switch/case statement to turn error codes into mnemonic strings. This requires a hardcoded list of all known errors, and a call out to this utility function every time you want to display the error reason in a readable way. I suggest adding the mnemonic string as a property of FileError, and displaying it as part of the toString. (See util.getFileErrorMnemonic() and util.installFileErrorToString() for example implementations.) Hmm...I'm not sure what other APIs usually do about this. As soon as you start adding strings that you intend
Re: [FileAPI] Result of calling MultipleReads on FileReader
On Fri, Apr 15, 2011 at 12:53 PM, Adrian Bateman adria...@microsoft.com wrote:
On Friday, April 15, 2011 12:16 PM, Arun Ranganathan wrote:
On 4/15/11 2:57 PM, Adrian Bateman wrote:
With this in mind, I don't personally have a strong feeling either way
between having to call abort() explicitly or having readAsXXX implicitly
call abort(). I've discussed it with others at Microsoft this week and the
consensus here is that the defensive exception is better and that
developers
should have to call abort() if they want to abandon the current operation.
I think we could live with either but right now we're planning for throwing
the exception. We'd like to make a decision one way or the other pretty
soon.
Adrian: I'm keen to have behavior similar to XHR, and not raise an
exception in this case. From your note above, I'm gathering you can
live with an XHR-style abort which FileReader can fire on readAsXXX
calls that have been superseded.
Yes, we could live with it but the semantics are more complex. Is this the
same
as calling abort() then readAsXXX()?
Yes. I.e. the semantics of readAsX is basically:
readAsX(...) {
if (requestInProgress)
abort();
... start new reading ...
}
When does the abort event get queued? What
will be the state of the reader at this point? Will loadend get fired? It
needs
careful speccing to make sure that the details are handled the same in
different
implementations.
Calling the abort() fires the abort and loadend events before the
function returns. Likewise readAsX fires the loadstart event before
it returns. So if a load has already started, then readAsX fires,
before it returns, the following events in order:
abort, loadend, loadstart
But indeed, the spec needs improvements here.
/ Jonas
Re: HTML5 Filesystem API feedback
On Wed, Apr 13, 2011 at 4:35 PM, Robert Ginda rgi...@chromium.org wrote: * The FileError object is a bit awkward to work with. I found that I frequently had every reason to expect my calls to succeed (because they were a follow-on to something that already succeeded), but I wanted to log the failure reason in the event they didn't. The code online suggests a switch/case statement to turn error codes into mnemonic strings. This requires a hardcoded list of all known errors, and a call out to this utility function every time you want to display the error reason in a readable way. I suggest adding the mnemonic string as a property of FileError, and displaying it as part of the toString. (See util.getFileErrorMnemonic() and util.installFileErrorToString() for example implementations.) I'd suggest solving this the same way as DOMException does, for consistency: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#exception-domexception It has a name property that contains the name, e.g., INDEX_SIZE_ERR or INVALID_STATE_ERR. Of course, if you want to display a real error message you have to localize it, but an easily-recognizable, memorable, Google-able string is still extremely useful in many cases. Plus, DOMException already does it and it's about two lines to spec, so why not?
Re: HTML5 Filesystem API feedback
On 4/15/11 6:29 PM, Aryeh Gregor wrote: On Wed, Apr 13, 2011 at 4:35 PM, Robert Gindargi...@chromium.org wrote: * The FileError object is a bit awkward to work with. I found that I frequently had every reason to expect my calls to succeed (because they were a follow-on to something that already succeeded), but I wanted to log the failure reason in the event they didn't. The code online suggests a switch/case statement to turn error codes into mnemonic strings. This requires a hardcoded list of all known errors, and a call out to this utility function every time you want to display the error reason in a readable way. I suggest adding the mnemonic string as a property of FileError, and displaying it as part of the toString. (See util.getFileErrorMnemonic() and util.installFileErrorToString() for example implementations.) I'd suggest solving this the same way as DOMException does, for consistency: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#exception-domexception It has a name property that contains the name, e.g., INDEX_SIZE_ERR or INVALID_STATE_ERR. Of course, if you want to display a real error message you have to localize it, but an easily-recognizable, memorable, Google-able string is still extremely useful in many cases. Plus, DOMException already does it and it's about two lines to spec, so why not? This sounds like a reasonable addition to both FileException and FileError; I'll make this change in File API. -- A*
