RE: [FileReader API, ProgressEvents] Design patterns, FileWriter API
Hi Arun, To be clear, IMHO it's absolutely too late for FileReader FileReader is still ED, therefore we may have time, I think. Regarding FileWriter, I'm open to considering new event names, but in general, discussing FileWriter's event model may be putting the cart in front of the horse. Even if we had an event-driven FileWriter, what would it do? We'll need to figure out filesystem access (real or virtual) first! :-) Agreed. I have been thinking in terms of API design patterns and IMHO their target is to first document what we have in order to be able to foresee potential incompatibilities. That is why I shout early :) Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: Arun Ranganathan [mailto:a...@mozilla.com] Sent: Thursday, November 19, 2009 12:55 AM To: Marcin Hanclik Cc: Anne van Kesteren; WebApps WG; public-device-a...@w3.org Subject: Re: [FileReader API, ProgressEvents] Design patterns, FileWriter API Marcin Hanclik wrote: Hi Anne, XHR still is used also for data retrieval, so it is a kind of border case and I can live with load there :) . Using load for writing to a file will mean that we are stuck with the legacy stuff. load and write pull semantically in the opposite directions, IMHO. I think there is still time to change it in case of FileReader and prepare background for FileWriter. To be clear, IMHO it's absolutely too late for FileReader, and also not desirable. I've already mentioned developer familiarity with onload, etc. and I strongly disagree with changing names in this case. The existing progress events are fine for FileReader. We've also got a beta implementation in place in Fx 3.6. Regarding FileWriter, I'm open to considering new event names, but in general, discussing FileWriter's event model may be putting the cart in front of the horse. Even if we had an event-driven FileWriter, what would it do? We'll need to figure out filesystem access (real or virtual) first! :-) More on this topic in separate email. -- A* Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: [FileReader API, ProgressEvents] Design patterns, FileWriter API
On Nov 19, 2009, at 11:35 , Marcin Hanclik wrote: To be clear, IMHO it's absolutely too late for FileReader FileReader is still ED, therefore we may have time, I think. Actually, it's published (as a WD) and has a rather long background history of previous development in the File Upload spec. I think I'm not the only one who would like this particular baby to move forward rather fast. -- Robin Berjon - http://berjon.com/
Re: [FileReader API, ProgressEvents] Design patterns, FileWriter API
On Wed, 18 Nov 2009 02:30:16 +0100, Arun Ranganathan a...@mozilla.com wrote: I think that just as the names 'load*' were chosen for generic data transfer events (either networked or within a document), and are used within documents loaded in the DOM, XHR, and FileReader, we'll need reusable 'write*' events. Without bikeshedding too much, I like your proposal above, but wonder whether we should use the name 'write*' or something else. Since we already have document.write, 'write' is probably the most vetted string to use here :) For what it's worth, for XMLHttpRequest sending events (which are arguably somewhat like write) we still use loadstart/... and simply dispatch them on a distinct object. I've no idea what the file writer API will look like, but I can imagine we might be able to do the same there. -- Anne van Kesteren http://annevankesteren.nl/
RE: [FileReader API, ProgressEvents] Design patterns, FileWriter API
Hi Anne, XHR still is used also for data retrieval, so it is a kind of border case and I can live with load there :) . Using load for writing to a file will mean that we are stuck with the legacy stuff. load and write pull semantically in the opposite directions, IMHO. I think there is still time to change it in case of FileReader and prepare background for FileWriter. I like the ProgressEvents spec and would keep it generic, i.e. change the names there to be generic and mandate their change in each spec that refer to ProgressEvents. PE is perfect to be a design pattern for asynchronous (and lengthy, more-than-one-shot, with-start-and-end, abortable and potentially erroneous) DAP APIs. In the firing grammar: progressgrammar = loadstart working (error | abort | load) loadend working = *( progress | (progress suspend progress) | (progress stalled progress) ) potentially rewritten to progressgrammar = start working (error | abort | done) end working = *( progress | (progress suspend progress) | (progress stalled progress) ) we would only need to change the working rule to accommodate various event firing scenarios. Thus under the same design pattern we could accommodate XHR, HTML5's media API, FileReader and any new DAP API. The event names could be related to the API for naming consistency, but firing model would be pre-defined were possible for design consistency. For example for directory walker (aka File Directory API or File API Level 3: Directories as proposed by Robin) we could have: directorywalkereventgrammar = start working (error | abort | done) end working = *( enterdir *file leavedir ) to be able to walk over e.g. 1M file entries in some FS. Any thoughts? I guess it may be over-engineering, but ... Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: Anne van Kesteren [mailto:ann...@opera.com] Sent: Wednesday, November 18, 2009 10:31 AM To: a...@mozilla.com; Marcin Hanclik Cc: WebApps WG; public-device-a...@w3.org Subject: Re: [FileReader API, ProgressEvents] Design patterns, FileWriter API On Wed, 18 Nov 2009 02:30:16 +0100, Arun Ranganathan a...@mozilla.com wrote: I think that just as the names 'load*' were chosen for generic data transfer events (either networked or within a document), and are used within documents loaded in the DOM, XHR, and FileReader, we'll need reusable 'write*' events. Without bikeshedding too much, I like your proposal above, but wonder whether we should use the name 'write*' or something else. Since we already have document.write, 'write' is probably the most vetted string to use here :) For what it's worth, for XMLHttpRequest sending events (which are arguably somewhat like write) we still use loadstart/... and simply dispatch them on a distinct object. I've no idea what the file writer API will look like, but I can imagine we might be able to do the same there. -- Anne van Kesteren http://annevankesteren.nl/ Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: [FileReader API, ProgressEvents] Design patterns, FileWriter API
Marcin Hanclik wrote: Hi Anne, XHR still is used also for data retrieval, so it is a kind of border case and I can live with load there :) . Using load for writing to a file will mean that we are stuck with the legacy stuff. load and write pull semantically in the opposite directions, IMHO. I think there is still time to change it in case of FileReader and prepare background for FileWriter. To be clear, IMHO it's absolutely too late for FileReader, and also not desirable. I've already mentioned developer familiarity with onload, etc. and I strongly disagree with changing names in this case. The existing progress events are fine for FileReader. We've also got a beta implementation in place in Fx 3.6. Regarding FileWriter, I'm open to considering new event names, but in general, discussing FileWriter's event model may be putting the cart in front of the horse. Even if we had an event-driven FileWriter, what would it do? We'll need to figure out filesystem access (real or virtual) first! :-) More on this topic in separate email. -- A*
Re: [FileReader API, ProgressEvents] Design patterns, FileWriter API
On Wed, 18 Nov 2009 02:30:16 +0100, Arun Ranganathan a...@mozilla.com wrote: Greetings Marcin, Thanks for the thoughtful feedback. My comments below: In my opinion some part of the design from ProgressEvents is taken over in FileReader API too directly. Specifically the event names are the same as within the ProgressEvents, ... What's in a name? [Floral poetry reference elided :-) ]. You are right to point out that there's some inconsistency in the naming convention. This discussion came up with the discussion of readyState [1] state name changes, when READING was considered as a potential readyState, were it not for consistency with the progress events in question (loadstart, load, loadend... ). We elected to stick to LOADING to match the names of existing progress events with 'load' in them. ... To date, you'll note that progress event nomenclature reflects loading or reading operations, since there are very few write metaphors on the web that have affiliated events bound to them. Actually, this is a false etiology. The naming conventions are based on what people were already implementing (as Robin says, it is often easier to extend the definition than change the term, as linguistics shows us over a far longer history than the Web). If the design of the FileWriter is similar to the design of the FileReader (which is something we're currently working on), then I think your names make sense. I don't actually. We have dumb names, because those are the terms we keep using... and the ones people are used to. Then, the ProgressEvents spec could act as a design pattern definition for lengthy, asynchronous operations. To make it happen, the names of the events there could be changed to be generic: I think that just as the names 'load*' were chosen for generic data transfer events (either networked or within a document), and are used within documents loaded in the DOM, XHR, and FileReader, we'll need reusable 'write*' events Actually, if the argument to keep the names makes sense, then it makes sense, so there is not much point in trying to separate out a bunch of things with a new name. Experience has shown it doesn't usually work anyway. loadstart - start progress stalled suspend error I like the proposal to have a section specific to data transfer and loading, but am wary of splitting specs. Input and feedback from the author of the ProgressEvents specification would be welcome here. The author is the Working Group - and ergo all the members. I'm just the editor. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [FileReader API, ProgressEvents] Design patterns, FileWriter API
Greetings Marcin, Thanks for the thoughtful feedback. My comments below: In my opinion some part of the design from ProgressEvents is taken over in FileReader API too directly. Specifically the event names are the same as within the ProgressEvents, but I assume they should be adjusted to the FileReader API. Therefore instead of (forgetting the above issue with the callback model for now): attribute Function onloadstart; attribute Function onprogress; attribute Function onload; attribute Function onabort; attribute Function onerror; attribute Function onloadend; we could have: attribute Function onreadstart; attribute Function onprogress; attribute Function onread; attribute Function onabort; attribute Function onerror; attribute Function onreadend; What's in a name? [Floral poetry reference elided :-) ]. You are right to point out that there's some inconsistency in the naming convention. This discussion came up with the discussion of readyState [1] state name changes, when READING was considered as a potential readyState, were it not for consistency with the progress events in question (loadstart, load, loadend... ). We elected to stick to LOADING to match the names of existing progress events with 'load' in them. I'll note that 'onload' is very ubiquitous on the web platform, and has been for a while now. These progress events are also used within XHR. This kind of consistency is very desirable for developer convenience, and in my opinion, trumps the perfect name consideration. We've used consistency in naming before in this specification. Here are a few other examples: 1. INTIAL -- EMPTY, for closer name similarity to HTMLMediaElement's network status. 2. mediaType -- type, for closer name similarity with style.type 3. Error conditions like NOT_FOUND_ERR, SECURITY_ERR, and ABORT_ERR are used in DOMException codes and XHR's error codes respectively, including with the same error code. Essentially, the argument here is to reuse what developers are familiar with. *In particular* I'm swayed by the pervasive use of 'onload' on the web. However, I like your next point: Assuming that we will have an interface like FileWriter in the (near) future, we could already now anticipate that the interface would include e.g. the following: attribute Function onwritestart; attribute Function onprogress; attribute Function onwrite; attribute Function onabort; attribute Function onerror; attribute Function onwriteend; To date, you'll note that progress event nomenclature reflects loading or reading operations, since there are very few write metaphors on the web that have affiliated events bound to them. If the design of the FileWriter is similar to the design of the FileReader (which is something we're currently working on), then I think your names make sense. Then, the ProgressEvents spec could act as a design pattern definition for lengthy, asynchronous operations. To make it happen, the names of the events there could be changed to be generic: I think that just as the names 'load*' were chosen for generic data transfer events (either networked or within a document), and are used within documents loaded in the DOM, XHR, and FileReader, we'll need reusable 'write*' events. Without bikeshedding too much, I like your proposal above, but wonder whether we should use the name 'write*' or something else. Since we already have document.write, 'write' is probably the most vetted string to use here :) loadstart - start progress stalled suspend error abort load - done loadend - end Sure. On this question I'm less opinionated. Additionally the ProgressEvents spec could be divided (or split into two documents? ) to contain the section specific to the design pattern definition and to the section specific to data transfer / loading. I like the proposal to have a section specific to data transfer and loading, but am wary of splitting specs. Input and feedback from the author of the ProgressEvents specification would be welcome here. -- A* [1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0691.html
