Filesystems Extension

$Revision: 1.2 $
Changes: available in CVS
Status: issue 16389

Abstract:

In order to replace the old data system functionality a new system called Filesystems Extension is proposed. Some of the features of the old system are dropped and new concepts are introduced. The goal of this effort is to enhance current functionality (by adding more extension points) while allowing for much simpler internal implementation.

What are we trying to solve?

Known problems of the old data system can be found here. Filesystems Extension is a replacement for part of the old data system functionality. Old DataObject did following:
  • groups together files (sometimes)
  • serves as a cookie container. Now Lookup.Provider.
  • owns the locking editor for the file, if any. Typically, an EditorSupport, with accompanying control over SaveCookie. Has a modified state that can be set, cleared, or queried.
  • performs any special operations when the file is copied, renamed, moved, or "created from template". For example, adjusts package and class name for Java sources, or replaces __NAME__ and similar macros.
  • defines a node delegate.
To successfully replace the functionality of the old DataObject and the rest of the org.openide.loaders package we have to:
  • use FileObject where possible
  • introduce Filesystems Extension
  • introduce real Settings API and use it instead of Datasystems
  • provide new from template functionality (since it is not covered by Filesystems Extension)
  • provide replacement for various little APIs currently in org.openide.loaders package

Proposals

  • User model document discusses the general principles for module writers.
  • Design document discusses implementation and contracts between modules using the Filesystems Extension API.

Open issues

Partially written files (or group of files)

MIME type recognition cannot proceed with a half-written file. Either we tighten up Filesystems threading, or just say that you need to use a FileSystem.AtomicAction, which should prevent the Filesystems Extension infrastructure from noticing the new file until it is complete. As for recognizing only some files, there is no problem - if a particular look wants to pay attention to other files in the same folder, that is its business.

One solution - implement firing of MIME type changes, and in the (hopefully rare) case that someone gets a MIME type before the atomic action exits, they will get a corrected type shortly afterwards. Pros: we might need to fire MIME changes anyway. Cons: more listeners; for some clients it may be too late to find out that the MIME type is wrong. Another - get a better threading design for Filesystems. #12417 for example. Mainly, give FileObject's real locks, or be able to lock a whole Filesystems, with a Mutex (i.e. writers lock out readers). Pros: more generally useful. Cons: more work.

Miscellanea

A forgotten minor capability of current DataLoader's: calling setImportant(false) on secondary files. I suggest this silly little method be deprecated and we either discard the notion entirely (new Projects will generally use separate build dirs, reducing the usefulness) or we let version-control filesystems provide some independent API giving a registry of unimportant MIME types. (Some VC filesystems will have their own techniques anyway, e.g. .cvsignore files.)

The DataObject.modified property and DataObject.Registry will probably need some kind of replacement. For example, a FileObject will already probably provide a SaveCookie when and only when it is modified. So some utility class needs to track the set of FileObject's which currently have SaveCookie's attached to them.

Re. the loaders package generally:

OperationListener: sad to say, people still use this. I think it would probably be subsumed by your Move interface etc. (operationMove etc.), template wizard iterators (operationCreateFromTemplate), and composite looks (operationPostCreate).

XMLDataObject and its various cookie-attaching capabilities can probably be replaced by looks on text/xml+foo.

ConnectionSupport should DIE. It is a job for MDR.

Folder sort mode and ordering: I suggest #18829 be considered, so that there is some API to sort a FileObject folder, set comparators, etc. One singleton comparator (or similar interface?) should use relative ordering constraints, as in DataFolder/FolderList now. Another would be a fixed order and would have a setOrder method. FilesChildrenLook.computeChildren should first hide files using DefaultFolderView, then sort the remaining ones. It should also provide a "Sorting Mode" property (type Comparator) where the default sorting mode is "alphabetical, but folders first, and taking into account any relative ordering constraints".

LoaderTransfer - what does this do that NodeTransfer doesn't??

OpenSupport - make a new subclass of CloneableOpenSupport that takes FileObject rather than MultiDataObject.Entry, easy enough (with #28497).

Backward compatiblity bridge

<TBD>
The bridge module is able to show the old data objects in the new looks base explorer and also to show nodes for the new types in the old explorer. It hides old secondary files in the new explorer but (for now (and maybe for good)) does not hide the new hidden files in the old explorer - I don't think this is necessary. If you disagree I would have to come up with some dirty trick to allow this.
</TBD>

How to get the sources?

Work on the API and bridge prototype has been started in an openide branch ds_16389_b. To access and build the modules follow these steps:
  1. Check out the branch
        cvs co -r ds_16389_b openide/ds
        cd nbbuild
        cvs upd -r ds_16389 build.xml build.properties
        
  2. Update text module to the branch (optional)
        cd ..
        cvs upd -r ds_16389_b text
        
  3. Build the whole NetBeans with the FS extension
        cd nbbuild/
        ant -Dmoduleconfig=fse
        


Project Features

About this Project

openide was started in November 2009, is owned by Antonin Nebuzelsky, and has 78 members.
By use of this website, you agree to the NetBeans Policies and Terms of Use (revision 20160708.bf2ac18). © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo
 
 
Close
loading
Please Confirm
Close