- From: Eric Uhrhane <ericu@google.com>
- Date: Tue, 15 Feb 2011 08:27:24 -0800
- To: Olli@pettay.fi
- Cc: public-webapps@w3.org
On Tue, Feb 15, 2011 at 3:46 AM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote: > On 02/12/2011 01:08 AM, Eric Uhrhane wrote: >> >> On Fri, Feb 11, 2011 at 7:43 AM, Olli Pettay<Olli.Pettay@helsinki.fi> >> wrote: >>> >>> Hi all, >>> >>> the current "File API: Directories and System" seems to use >>> callbacks and not events, yet other >>> File APIs (the ones for read and write) use events. >>> That is quite major inconsistency in the APIs. >>> IIRC there was already some discussion about which approach to use >>> when the API for read was designed and it was decided that events should >>> be >>> used. >>> >>> Using events would make it rather easy to track moves, copies etc, of a >>> file. Just set the event listeners when the entry is first time >>> accessed, and then you get notified whenever the file is moved etc. >> >> FileReader and FileWriter are fundamentally different than FileSystem. >> Reading or writing a file is an ongoing process, hence progress >> events make a lot of sense. Getting a file handle, deleting a file, >> creating a directory, etc., are all very binary. They've happened or >> they haven't, and there's no progress to report. Thus callbacks make >> sense for those operations. >> >> It sounds like you're looking for some sort of a FileSystemWatcher >> object that would let you keep track of everything that's happening in >> a filesystem. > > No I'm not, although using events would give that kind of > functionality for free. There is no "free". > I'm looking for API consistency. Different APIs have different requirements and fulfill different use cases. There will inevitably be differences in interface. > That's not a request I've heard before; if you've got >> >> specific use cases in mind, please post them. >> >> Eric >> >> > >
Received on Tuesday, 15 February 2011 16:28:16 UTC