[tahoe-dev] FUSE and Tahoe

[rob kinninmont]

On Oct 3, 2008, at 12:15 AM, Brian Warner wrote:

> When I looked at FUSE a long while back (at least 4 years ago), I  
> remember
> they were just making the transition from the blocking one-request- 
> at-a-time
> simple-code lots-of-threads model to a more sophisticated
> operation-id+callback event-driven system. In the subsequent python  
> bindings,
> it was never clear to me which form you'd get access to. It sounds  
> like
> they aren't entirely clear on this issue either :).

the fuse_main stuff dispatches your handler functions on various  
threads. (I'm pretty sure that there's a 'single threaded' alternative  
but I think that's strictly less functional, just safer)

having poked my head under the covers of Armin's pyfuse stuff, I think  
the operation id business is how the actual fuse requests come over  
the fuse socket into user space, and hence it's the fuse_main parts of  
libfuse that are decoding that into the 'simpler' form.

> PS: your dirnode caching strategy sounds excellent. I'm working on  
> an FTP
> server right now, and will probably wind up with something similar.

Code re-use is our friend!  Let's aim for the *same* rather than  
'similar', if we can.  I'm in no way opposed to revision / refinement  
of those parts of the fuse code base, it's basically just an in-memory  
object model for encapsulating tahoe files and folders (webapi backed,  
in this case).

I'd really like to see this code more twisted-oriented, and whether it  
makes sense to switch to foolscap in preference to webapi, or even  
something crazy like putting that sort of caching layer inside the  
tahoe node itself, I'd like it to be flexible and generally useful :-)

cheers,
rob