Filesystems Extension
$Revision: 1.6 $
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:
- Check out the branch
cvs co -r ds_16389_b openide/ds
cd nbbuild
cvs upd -r ds_16389 build.xml build.properties
- Update text module to the branch (optional)
cd ..
cvs upd -r ds_16389_b text
- Build the whole NetBeans with the FS extension
cd nbbuild/
ant -Dmoduleconfig=fse
