Suggestion: FUSE low-level binding to Node

[r...@tinyclouds.org]

FUSE low-level is a completely asynchronous API which would meld
perfectly with Node. Someone should make a binding to enable us to
throw together little filesystems. I would very much like to mount my
web server.

Here is fuse_lowlevel.h : http://gist.github.com/459470

[Ben Noordhuis]

I might do it, I've worked with FUSE before. But you'll have to give
me one good reason *why*! :-)

On a tangential note, is anyone working on Node support for SWIG[1]?
You'd only need to write a single interface file, then SWIG will
generate the bindings for you. Something like the below is probably
all that is required to create a FUSE module.

%module fuse
%{
#include <fuse.h>
%}
%include <fuse.h>

Doesn't get much simpler than that, does it?

[1] http://www.swig.org/

[Tim Caswell]

Any update on this?  I still think this would be super useful.  I saw Isaac has an empty repo on github, but that was all I could find.

[Isaac Schlueter]

I've done a bit of exploration in a branch there.

The next step is to basically set up a custom libeio loop, and move
over all the logic from the fuse_loop into that. The API I had in
mind was something like:

var fuse = require("fuse")
fuse.mount("/some/path",
{ "stat" : function (path, cb) { cb(error, stat object) }
, "open" : function (path, mode, cb ) { cb(error, fd) }
, "read" : ...
})

With perhaps some default dummy stuff in there so that un-handled
things return an error rather than a total segfault failure.

--i

On Mon, Jan 24, 2011 at 12:31, Tim Caswell <t...@creationix.com> wrote:
> Any update on this?  I still think this would be super useful.  I saw Isaac
> has an empty repo on github, but that was all I could find.
>

> --
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com.
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en.
>

[Ryan Dahl]

On Mon, Jan 24, 2011 at 4:05 PM, Isaac Schlueter <i...@izs.me> wrote:
> I've done a bit of exploration in a branch there.
>
> The next step is to basically set up a custom libeio loop, and move
> over all the logic from the fuse_loop into that.  The API I had in
> mind was something like:

You should be able to do it on the main loop. I've got code samples on
how to poll it from libev.

[Jan Winkelmann]

Hi,

since I need fuse for a project and Isaac stalled his work for the
moment I'll try to push this forward and do it myself. I'm not really
experienced with node or the v8 api, but I think I can handle it. I
made a fork[0] if isaacs github repo, I haven't pushed anything
important yet, though.

On Jan 25, 1:05 am, Isaac Schlueter <i...@izs.me> wrote:
> [snip]

> The API I had in
> mind was something like:
>
> var fuse = require("fuse")
> fuse.mount("/some/path",
>   { "stat" : function (path, cb) { cb(error, stat object) }
>   , "open" : function (path, mode, cb ) { cb(error, fd) }
>   , "read" : ...
>   })

> [snip]

Also, since this should be a low-level binding, we might not want the
abstraction of using paths instead of inodes. To be honest, I don't
see a use case right now, but I feel like this is the responsability
of a higher level library (or we provide both). What do you guys
think?

-Jan

[0]: http://github.com/keks/node-fuse

[Tim Caswell]

Filenames probably makes more sense to high-level things, but whatever is easiest to implement and lets me make custom file systems in node is fine by me.

--

[Isaac Schlueter]

Well, I felt like it should mirror node's fs module, with the
necessary proxies and renaming in the fuse binding to make that
possible.

So, node's fs.open looks like: fs.open(path, flags, mode=0666, [callback])
and then the callback gets called with callback(err, fd), where err is
null or an error, and fd is the file descriptor, if it was opened
successfully.

In a node-fuse filesystem, the object you provide would (in order to
implement the "open" call) implement a method that looks like:
open(path, flags, mode=0666, [callback]) and then at some point
*calls* the callback argument (if provided) with either (err, fd).

You should be able to say "Reverse the arguments and function names
from the 'fs' lib to implement a filesystem", and then a fuse fs
object could look just like the fs module. In fact, you'd even be
able to pass the fs module *itself* into fuse.mount in order to mount
one file system onto another.

So that's why I imagined the cb's taking paths rather than inodes.
But if you wanna run with this ball for a while, by all means, take it
wherever you wanna go.

--i

[Jan Winkelmann]

Alright, I'll try to make it clean and working :)