Hi, Looks good so far. A few questions
In FileName why have getChild() when there is resolveFile() that does that and much more? Same goes in FileObject? In FileContent why do you have an "encoding" attribute and how do you imagine it retrieved for a file. Personally it seems to me that and the FileReader may be a littl emisplaced as it is not possible to determine the encoding of the file from most file system types. In FileContent lastModifiedTime is represented as a Date rather than a long. wouldn't it be more efficient to work with longs? How do you do a rename? The 2 arg findFile() in FileSystemManager seems out of place - why dont you just directly resolve name against basefile? The FileSystemManager also seems a bit of a misnomer because it represents the root of a file tree. So maybe just FileSystem would be a better term? Also what other attributes do you think we could apply to trees? On Thu, 17 Jan 2002 22:07, Adam Murdoch wrote: > The goal for this first cut was to do up a proof-of-concept. I'd love to > get some feedback from ant-dev. The javadoc for the API interfaces is > attached (I've left out the provider API, cause it's just noise at this > stage). Please have a read - comments most welcome. Just keep in mind it > ain't finished yet. If it looks ok, I'll tidy-up the code (license, > package names, etc) and send it in. sounds good to me :) > The next step would be to try it out. I'd like to do this in Myrmidon, if > possible. The plan would be something like: > > * Do up a FileSystemManager impl that wires into myrmidon. +1 > * Expose the FileSystemManager to the tasks via TaskContext as (ultimately) > a replacement for getBaseDirectory() and resolveFile(). Could be done via > ComponentManager + AbstractTask too, I suppose. I would like to keep getBaseDirectory() and resolveFile() for now because tasks could be used in places where a VFS is overkill. Maybe the best way to expose this and other services to tasks is via adding a method to the context such as Object getService( Class clazz ); SO you would do something like final FileSystemManager manager = getContext().getService( FileSystemManager.class ); That way we can remove Composable/ComponentManager from tasks where it was kinda overkill. > * Add a String -> FileObject converter. +1 > * Port FileSet and Path to use FileObject and friends, rather than > java.io.File. Would involve pushing some of this stuff behind the API. I woul dbe interested in seeing how you plan to do this. > * Port <move>, <copy>, <mkdir>, <touch> and <delete>. Again, some of this > stuff would end up behind the API. kool. Until VFS is completely up and running it may be best to fork those tasks in myrmidon and then when the VFS is stable just remove the old versions? > * Look at things like configuring file systems in the build file, getting > user name and password from the user, etc. How do you think this should happen ? > * Get the FS providers involved in searching, deleting, moving, and > copying. Do as much as possible of this remotely. +1 > * Layered FS, compound FS, filtering, +1 > a concurrency model, etc. shouldn't we delegate to the underlying provider? -- Cheers, Pete ---------------------------------------------------------------- Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it. -- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982 ---------------------------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
