ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <adammurdoch...@yahoo.com>
Subject RE: Ant2 VFS Proposal
Date Wed, 23 Jan 2002 00:10:54 GMT


> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> 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:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message