On Wed, 22 Jan 2003 03:41 am, Jeff Barrett wrote: > Here's some things I was mulling over last night: > > - There seems to be some overlap in concepts/goals between FileName and > Uri. Perhaps they should be combined somehow.
Yep, good idea. Could probably also merge in most of the UriParser heirarchy too. The plan for separating them out was to allow us to deal with all kinds of weird naming schemes. But that flexibility hasn't been needed. And there's real benefit in having just one naming scheme, which works consistently across all file system types. So, yes, we could definitely squish them all into a single FileName heirarchy, and do away with that flexibility/complexity. I'd also like to make Uri (or something like it) part of the public API. Right now, the only way to look-up a file is to using a string URI (and having to deal with formatting and encoding). It'd be nice to also be able to do something like: FtpFileName fileName = new FtpFileName(); fileName.setHost( hostname ); fileName.setUserName( username ); fileName.setPath( path ); FileObject file = fsManager.findFile( fileName ); This would fall out of combining FileName and Uri. > - There's a lot of functionality inside FileObject: including > getChildren(), getParent(), resolveFile(), create(), delete(), etc. . One > advantage to this is only needing one object, a FileObject, to get all > sorts of this work done. Alternatively, these calls could be made to > FileSystem directly, with a FileObject passed in. Since most of these > methods that are currently in FileObject end up calling FileSystem anyway a > lot of the work is already done. This would reduce the duplication in apis > between FileObject and FileSystem. It might also make it a bit clearer > where the responsibility is. I think you can break the methods into 2 broad categories: - Those that operate on the file itself: getContent(), create(), delete(), getName(), etc. - Those that find a file: - Some are relative to a particular file, like FileObject.getParent(), resolveFile(), findFiles(), etc. - Some are relative to a particular file system, like FileSystem.getRoot() or FileSystem.resolveFile(). - Some are absolute, like FileSystemManager.resolveFile() or toFileObject(). The best place for the first group is FileObject, I think. This places the operations close to the thing that they operate on. Maybe a case could be made for replacing FileObject.copyFrom() with something like FileSystem.copy( srcFile, destFile ). For the second group, you could certainly collapse them all into something like: - FileSystemManager.resolveFile( FileObject baseFile, String uri ) - String[] FileObject.listChildren(). All the other 'find a file' methods are really just convenience methods. The approach I like to take to API design is to move code from places that are implemented many times (ie the API clients, and API plug-ins), to places that are implemented once (ie the framework). That's what these convenience methods do. Maybe there are too many, or maybe they're not particularly well named. But I don't think it's a good idea to get rid of all of them. > - taking the last idea a little further, it might be cleaner/clearer to > move most/all FileObject creation into FileSystem and it's subclasses. FileSystem is ultimately responsible for locating and creating FileObjects. Everything else delegates to it. The provider API could definitely do with some work to make this clearer. And maybe the public API could be tweaked to reflect this too. Though, I do think there's benefit in having those convenience methods on the public API. > One > of the hardest things for me in getting up to speed with the code was > understanding the creation of FileObjects. In the index of the API docs, > there are 19 different resolveFile methods in various class hierarchies. > There is also FileProvider.findFile(), FileObject.findFiles(), and > LocalFileProvider.findLocalFile(). Sure, but you're mixing up the public API, the provider API, and the framework here. The provider API definitely needs work. No question. But I'm more interested in getting the public API right. So let's just take the org.apache.commons.vfs package, and ignore all its subpackages - what do you think the complexities there are? > - it may be useful to explore the idea of removing FileObject's refererence > to it's FileSystem alltogether Maybe. Some FileObject implementations do need to get at their file system, eg FtpFileObject or JarFileObject. I don't think there's necessarily anything wrong with attaching a FileObject to a FileSystem. Some operations work on a single file - they belong on FileObject. Some operations work on a bunch of files - they belong on FileSystem. > - For consistency: Unless I'm missing some meaning, and I totally could be, > AbstractFileSystemProvider, DefaultLocalFileSystemProvider, > ZipFileSystemProvider, JarFileSystemProvider, FtpFileSystemProvider, > SmbFileSystemProvider should all be FileProvider not FileSystemProvider > since that's the interface they implement. Or FileProvider should be > renamed along with it's similarly named implementors. Yep. FileProvider used to be called FileSystemProvider. I just never got round to renaming everything else. I might just change it back. > - the reasoning behind what classes go in org.commons.vfs.impl versus > org.commons.vfs.provider is a little confusing. The provider package contains the provider API (such as it is), the impl package contains the framework that assembles everything together. > That's all I can think of at the moment. How do these sound? They sound good. Thanks for the feedback. -- Adam -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
