> -----Original Message-----
> From: Peter Donald [mailto:[EMAIL PROTECTED]
> Sent: Monday, 21 January 2002 8:12 PM
> To: Ant Developers List
> Subject: Re: Ant2 VFS Proposal
>
>
> On Sun, 20 Jan 2002 17:53, Adam Murdoch wrote:
> > 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.
>
Some terminology that the API uses:
A 'file system' == a single tree. Right now, file systems are implicit, and
there is no way to control them via the API. For example, if you ask for
"smb://somehost/someshare/a/file", you get the file "/a/file" in the file
system "smb://somehost/someshare". It would be good to add stuff to the API to
allow control this. For example, it might be handy to programmatically
configure the file system, or to specify where the root of the file system
should be.
A 'provider' == a single type. Same thing, there's no way to control providers
via the API.
As for FileSystemManager, it manages a set of file systems. It's intended to
be used as a part of the task context: The container hands a task a
FileSystemManager which the task uses to access the file systems. The
FileSystemManager may come pre-configured with a fixed set of file systems, or
it may create them on-the-fly (as the current default impl does), or may only
hand out read-only file systems. Whatever.
> > * 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
>
That would work, provided it was relatively streamlined. For example, I'd only
want to be prompted if 1) the file system needed login info, and 2) I hadn't
provided the info in my preferences.
It would be a good thing to (optionally, of couse) have a separate namespace
for things like username/passwords, so that they are only available to those
services that need them, but not visible to the whole world as properties.
Regardless, this is all nitpick type stuff. Properties and <prompt> would be
fine.
> > > > 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).
The approach I'd like to take with the API is:
* Guarantee that certain functionality is available in all providers, and
behaves consistently across all providers. Some examples: providers must
handle paths with / and \ separators. Or, providers must throw an exception on
an attempt to read the content of something that is not a file. Searching
would also fall under this category - providers will have to support searching,
and will have to be able to handle the Ant-style path wildcards. ("provider"
here means "provider, with the help of the VFS framework").
* Make other functionality optional, but guarantee that it behaves consistently
across all providers for which it is available. Some examples: Delete must be
recursive, if delete is supported. Or, the parent folder must be implicitly
created when writing to a new file, if writing to files is supported.
* Allow provider-specific functionality to be exposed, but make no guarantees
about its availablility, or portability. Some examples: The set of attributes
supported for files is unspecified. Or caching - a provider can cache whatever
and however it wants.
I think that the tasks' needs should drive where a particular feature sits.
Features like concurrency detection can start in the third category, and work
their way up, if they prove useful.
Adam
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
