From: "Adam Murdoch" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
