Re: Libferris support in TRAMP

[Ben Martin]

On Mon, 2010-03-01 at 16:50 +0100, Michael Albinus wrote: 
> Ben Martin <address@hidden> writes:
> 
> > Hi,
> 
> Hi Ben,
> 
> >   I'm the author of the libferris virtual filesystem [1]. I've been
> > meaning to add libferris support to TRAMP for many years, unfortunately
> > it has been keeping many items on the TODO list company and didn't get
> > any time until recently.
> >
> >   The attached patch is certainly not for applying, but is attached in
> > the interest of raising comments.
> >
> >   I was originally poking around the lisp sources for the various things
> > that TRAMP can use as a virtual filesystem when a fairly clean design
> > hit me. Instead of bringing TRAMP to libferris, why not do the opposite?
> 
> Fair enough. What I'm curious about: does libferris also cooperate with
> core Emacs? That is, is it possible to use libferris virtual files in
> Emacs without Tramp? Otherwise, it might be necessary always to open an
> ssh connection (or something like this), even for local files.

Well, I do have FUSE integration to allow direct interaction. I find
fuse to be a bit heavy handed for some things though, for example, using
fcat I can peek into an XML file directly without any explicit "mount"
command.

Although needing to ssh localhost seems a bit odd, if you are planning
to edit part of an XML file or a tuple in a database, such a setup step
is probably not a huge issue.

> 
> >   So I started digging into the main tramp.el file and tracing ssh
> > connections to see what commands were executed in the background. I
> > already have replacements for many of the normal coreutils programs:
> > fcat, ferrisls, ferriscp, ferris-redirect etc, so the plan was to try to
> > get TRAMP to just use the libferris implementation of these commands.
> 
> If we do this, we need a trigger whether to use libferris on the remote
> side, or not. We would need to say /ssh:... for usage of core POSIX
> commands, and /ssh+ferris:... for usage of libferris command
> replacements. Even if we have a global trigger ("use always libferris
> commands"), it sounds like adding complexity to Tramp.

I now also have completions working with libferris thanks to a ferrisls
-F derivative which only classifies directories
(--classify-directories).

I suspect we are on the same page here with the ssh+ferris method. I was
thinking as far as making the patch less intrusive goes, adding to
tramp-methods this ssh+ferris object and including things like for
example,
tramp-posix-ls-command
tramp-posix-cp-command 
where a nil would perhaps induce "ls" and "cp" to be used. Though for
this part just telling tramp to use a specific shell init file could
allow the shell itself to alias ls=ferrisls etc. The knowledge of things
like the added --classify-directories switch to ferrisls is harder to
sweep away, along with the redirection changes.

So, for the patch there is complexity in at least 3 places in tramp that
I can't easily work out how to sweep away:
1) completion with --classify-directories
2) redirection into a file   (> becomes | ferris-redirect -T)
3) redirection out of a file (< $file becomes fcat $file)

> 
> >   The only two areas where this would not work cleanly is the base64
> > inline transmission. For example, encoding
> > (format "%s < %s" 
> >   rem-enc 
> >   (tramp-shell-quote-argument localname))
> > doesn't work for libferris because the shell redirection doesn't know
> > how to handle my filesystems. The work around is simple in this case,
> > just cat the file to the base64 encoder:
> > (format "fcat %s | %s" 
> >   (tramp-shell-quote-argument localname)
> >   rem-enc 
> >   )
> 
> This would limit the libferris command set to Tramp's inline
> encoding. That means, something like "scp" cannot be applied for remote
> libferris files, right?

Not directly. One could use rsync with the FUSE wrapper or various other
incantations, but for now even if the libferris stuff is limited to the
inline encoding it is a start.

> 
> > As a small usage example, on the remote server;
> >
> > $ fcreate --create-type=db4 --rdn=isam.db .
> 
> Hmm. I would like to follow your examples. Unfortunately, I haven't
> found a simple recipe, how to download and install libferris on my
> machine (I'm running Ubuntu, btw). Going to
> http://sourceforge.net/projects/witme/files/ as instructed on your
> download page doesn't tell me too much. What do I need really for the
> beginning? How to install?
> 

http://www.libferris.com/buildorder
Although the graph looks a bit scarey, much of the stuff should already
be available packaged. You will probably need to build and install
libferrisloki, libferrisstreams, stldb4, fampp2, libferris,
ferriscreate, in that order.

Once upon a time I used to try to maintain packages for Ubuntu and
openSUSE too. These days I do Fedora and maemo (Diablo only until I get
an n900). The quickest way to play around would be to install libferris
from OBS on a Fedora virtual machine.

> Another idea would be to use your FUSE interface of libferris. That's
> what Tramp already does for GVS offered files. They are "mounted" on the
> fly, and Tramp only needs to show them with its own
> syntax. "/ferris::/tmp/isam.db/subfile1" would be a local file, and
> "/ferris:address@hidden:/tmp/isam.db/subfile1" would be a remote file
> (accessed via ssh, for example - that needs to be configured). What do
> you think about?

That was my initial thought of how to implement things, but then I
wondered how much would need to change to avoid using FUSE. Without FUSE
for example, I should be able to grab into files on a maemo device which
might not have the FUSE kernel module. Ultimately, I might work on
support for both ways; the FUSE solution being much less intrusive to
the tramp code and thus more likely to go mainline.

> 
> Best regards, Michael.

signature.asc
Description: This is a digitally signed message part