On Sun, 20 Jan 2002 17:53, Adam Murdoch wrote:
> > How do you do a rename?
>
> Well, you wait for the second cut, when there will be methods like
> FileObject.move() and FileObject.copy(). Or you can send me a patch (with
> test cases please) :)
For me to send a patch you would first need to send the source ;)
> FileSystemManager.findFile() will find files in any file system. You use
> this if you don't know what the name is (e.g. something from a build file).
> The 2 args version allows you to specify the base file to use, if the name
> happens to be relative.
Okay - I think I am lost again ;)
Is FileSystemManager a single tree (ie "C:\"), a single type (ie "file:") or
a system-wide service. If it isn't the last I am not sure that the findFile
should be able to cross different namespaces/filesystems.
> > > * 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.
>
> Something like:
>
> * Refactor <fileset>, similar to <path>, to clean it up and get it working
> with java.io.File. Probably extract an interface for <fileset> and <path>
> to share, as most tasks simply need a set of files, and could just as
> easily take a <fileset> or a <path> (or, say, a <java-runtime> or a <file>
> or a <swing-file-chooser>). This was going to be the starting point for
> playing with type substitution.
>
> * Move <fileset> and <path> (and the related classes) to
> org.apache.antlib.<somewhere>. Any thoughts where?
I would move them to org.apache.antlib.framework.* because they will most
likely want to be used by multiple applications.
> > > * 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?
>
> Sure - how about into package org.apache.antlib.file?
works for me - or maybe org.apache.antlib.vfile
> * The ability to get the user-name and password from the user's
> preferences, or prompt for them, if not specified in the URI.
I think this should be done with properties and a separate <prompt /> task or
similar? Thoughts. We already have an <input/> task in ant1.x, this could be
generalized for loading more properties or something
> > > a concurrency model, etc.
> >
> > shouldn't we delegate to the underlying provider?
>
> Sure. The question would be what the provider has to guarantee to support,
> and what is optional. E.g. Should it guarantee to detect concurrent read
> and write? Is it just a nice thing for it to do? How about dealing with
> files that have more than one name (case-insensitive, links, aliases, etc)?
> Should it consider these the same file when doing the detection?
I wouldn't bother with concurrency detection as such - I would just make sure
that the in memory representation is consistent and the underlying provider
API semantics are maintained (which would mean blocking for certain requests
over ftp for example).
--
Cheers,
Pete
---------------------------------------------
We shall not cease from exploration, and the
end of all our exploring will be to arrive
where we started and know the place for the
first time -- T.S. Eliot
---------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
