ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Magesh Umasankar" <umag...@apache.org>
Subject Re: Virtual FileSystem Layer
Date Sat, 22 Dec 2001 03:38:04 GMT
From: "Adam Murdoch" <adammurdoch_ml@yahoo.com>

First of all, Adam, this material is quite something that
you have put together.  While going through it, I couldn't
help but notice the similarities of what you have listed to
that available in the JNDI API, which in fact further
boosts my sales pitch for using JNDI ;-)

> The API also has to be general enough to deal with stuff we haven't
thought
> of yet.  On that note, I personally think that JNDI might be a touch too
> general for what we need.

JNDI is designed to be a bit general, but it seems like we do
need *a lot* of what it provides.  I will try to map your inputs to
APIs/nomenclature in the JNDI world.

> So, the features.  Note that many of these will be optional - not every
> feature will be available for every node in the file system.  I've used
the

javax.naming.OperationNotSupportedException will be thrown
by those service providers which do not implement a certain
method.

> term "node" to mean both directories and files.  I'm not suggesting we

Node is roughly equivalent to DirContext in the JNDI world.  DirContext
is a collection of sub DirContexts and 'FileResources' (aka files).

> actually call them "nodes" in the API.  I've used the term "root node" to
> mean the root of a file system.

Docbase for a DirContext is its root.

> * Naming
>
> - Locate a node by absolute name.

Context.PROVIDER_URL can be used to locate by abolute name
or to identify the docbase, apart from resolving protocol, userid,
password, etc.

> - Get the absolute name for a node.
> - Resolve a name to a node, relative to some base node - like
> FileUtils.resolveFile().
> - Get the relative name of a node, relative to some base node.
> - Determine the base name (with and without the extension), and extension
of
> the node.
> - Deal with file systems that are case sensitive, and case insentitive.

Custom APIs implemented when extending the DirContext.  Also
implementing lookup, lookuplink, etc. would solve portions of this.

> * Properties
Properties map to DirContext "Attributes" in JNDI and you
can perform all the operations you have mentioned below by
implementing the Attribute interface.

> - Determine what properties are available on the node.
> - Determine if the node exists.
> - Determine the type of node (file vs. directory, could be "has-content"
vs
> "has-children").
> - Determine if the node is readable.
> - Determine if the node is writeable.
> - Get/set the permissions on the node.  This covers things like chmod &
> chown, making read-only, making executable, etc.

>
> * Content
>
> - Determine if the node can/does have content.
> - Get the size of the node.
> - Get/set the last-modified time of the node.
> - Get/set the mime-type of the node.
> - Get/set the encoding of the node.
> - Get a checksum of the node.
> - Get content as InputStream.
> - Get content as Reader.
> - Set content as an OutputStream.
> - Set content as a Writer.
> - Implicit creation of node and its ancestors when content is written.
> - Compare nodes for equality (last modified timestamp, checksum, bytewise
> compare).

You would be able to handle streams using the FileResource.

>
> * Hierarchy
>
> - Get the parent node of a node.
> - Get the child nodes of a node.

lookup, lookuplink...

> - Iterate over (or visit) the descendants of a node.
>   - With or without a selector.
>   - In various orders - depthwise, etc.
>   - Be able to modify the nodes during traversal.

Implementation of DirContext's search methoids by defining
SearchControls.

>
> * Modification
>
> - Create a new node of a particular type.  Create all missing ancestors.
createSubContext

> - Move, copy, delete a node.
DirContext.destroySubContext, rename, unbind, rebind, etc.

>   - All descendants.
>   - Optional selector. E.g. ignore empty dirs, ignore default excludes,
etc.
>   - Optional filter.
DirContext.modifyAttributes

> * Conversion
>
> - Convert the node to a java.net.URL.
> - Make the node content available as a local file (to hand off to external
> commands).
> - Get the OS specific *filename* for a node.
> - Resolve an OS specific *filename* to a node.

Custom APIs.

>
> * File System Types
>
> - Local file.
> - HTTP.
> - FTP.
> - Classloader, uses Classloader.getResource().
> - Temporary files.
> - etc ...

These will be individual JNDI Service Providers.

> - Compound file system.  Made up of a bunch of mount points.  The VFS
> itself.
>
> - Layered file systems (that sit on top of another file system or node):
>   - zip, bzip, jar, tar
This is equivalent CompositeName in the JNDI world.

>   - filtering - token replacement, etc
>
> - Factories for creating and configuring file system root nodes.

InitialContextFactory in JNDI...

> - Ability to easily add new file system implementations.

It would take defining a JNDI ServiceProvider...


> * Other things
>
> - Maybe some way to explicitly close a node and release all resources used
> by it.
>
> - Maybe detection of concurrent updates, in the case of parallel tasks.

Implementing SPI in a threaded model.

>
> - Netbeans has an event model in its VFS.  Something like this might be
> useful in dependency management.

JNDI too has an event model.  javax.naming.event, which offers
sophisticated functionality.

Summarizing, I just can't help but notice the similarities that
JNDI provides to what you have put together.  I don't want us to
reinvent the wheel if we can avoid it.

Cheers,
Magesh




--
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