Plugins superclass and refactoring
Charles Parnot
that the shared code could reside in a separate superclass
implemented in the main app. Plugins would then just have to link to
the main code (already done in rev219): using the bundle_loader build
setting) and only implement the little code needed to define the
NSTask for the client filesystem, and then maybe the additional
settings to be saved in the preferences.
One of my motivation was to make the developement of other plugins
even easier. I have found in developing an Xgrid FUSE plugin that 90%
of the code for the main class was copied and pasted from SSHFS.m. It
was still very easy, but it seemed superfluous.
Here is what I did yesterday:
* Superclass MacFusionFileSystem takes care of most of the stuff that
most filesystem plugins will have to do:
* keep track of name, status, mountOnStartup (default NO)
* also keeps track of hostName, login, path, which is useful for
filesystem connecting to a server (e.g. FTPFS, SSHFS, XgridFS,...)
* also manages the process that corresponds to the client
filesystem: start it, checks the output, checks termination,...
* Subclass SSHFS. I trimmed down the code to use the superclass
MacFusionFileSystem (now 180 total lines in SSHFS.m instead of 550!).
Most of the code is for defining the NSTask to launch the sshfs-
static process.
* Use that to also rewrite my XgridFS plugin (just 7 statements in
XGRIDFS.m!).
So far, everything seems to behave fine (I did not even corrupt my
preferences...).
Next steps would be:
* add to svn??
* test more
* trim FTPSH to also use the superclass (that would also tell if I
missed something important in the superclass design)
* test more
* add to svn??
* test more
* simplify the controller class. From what I can tell, MacFusion
could provide a default controller class and the plugin would not
even necessarily need to provide one. It would be OK to leave the
possibility for a custom controller class for potential cases where
it would be needed (I can already think of a reason for XgridFS). In
fact, probably the default controller class could also be used as the
superclass for custom controllers.
* test more
* add to svn??
Regarding the 'add to svn??' steps: I don't even know if you would be
interested in incorporating these changes in the first place (in
which case anyway, I would define the superclass in my plugin, the
code of which will be available at some point). And if you do want to
incorporate those changes, I don't know what the project policy is in
terms of stability of the trunk (or if there is a policy ;-). This
kind of refactoring can trigger bugs and instabilities, so I don't
know if you would test things first, have that on a branch for a
while, or something.
In any case, here are the files corresponding to the changes
mentioned above:
http://cmgm.stanford.edu/~cparnot/temp/superclass.zip
What do you think?
charles
--
Xgrid-at-Stanford
Help science move fast forward:
http://cmgm.stanford.edu/~cparnot/xgrid-stanford
Charles Parnot
charles...@gmail.com
Michael Gorbach
Thanks for your help, I appreciate it!
I'll be branching the SVN repository later this week and we'll put
this class in the new trunk.
Michael