Jean-Paul Calderone <exar...@twistedmatrix.com> writes: >> My view is that the interface to filesystems is via the normal kernel >> filesystem system calls, and that filesystems can be implemented in >> kernel (typical for local on disk) or via FUSE or similar. >> >> tahoe's interface is of course richer, and thus one would need to have a >> parallel interface or work that into extended attributes or special >> ioctls. Coda went down the special ioctl route. >> >> This view is basically saying "it's not good to make access only by >> command line programs; that feels like mtools". > > This all sounds pretty reasonable to me too. I think performance has been > a major challenge with presenting a native filesystem interface in the > past. The current implementation's performance properties mismatch the > properties of "normal" filesystem access so much that when this interface > is presented the experience still ends up being pretty bad. I don't see > why this *necessarily* should be the case - at least to the current degree > - so I'm hopeful that with some attention to improving performance > something in this direction might be viable.
(slightly fuzzy from memory) Coda had the idea of keeping a file in local cache when being written and only starting the network write process after a short delay, or at least one close. I reailze that turning every write system call into a tahoe write operation is real trouble. I suspect that is the major issue. The other issue is the management interface, but I view that as just work, not conceptually tricky. >> Another interesting example is Nextcloud, which is WebDAV but has a >> client that will sync webdav to local (so you get offline access). I'm >> not sure offline access makes sense, but the point is that they thought >> it best to provide a way to interact with data on Nextcloud from >> programs that have no idea nextcloud exists, just by choosing a >> directory in the right place. > > This is a bit like what magic-folder > <https://github.com/LeastAuthority/magic-folder/> does so I think we've > decided it *does* make sense, at least for some use-cases. Yes, that is what I meant. (As a packaging comment, asking for pinned dependencies is not reasonable because that basically makes it unpackageable and venv only.) I do wonder about full sync from vs FUSE access and caching, which is sort of reinventing coda with backend on tahoe-lafs. The point is that tahoe-lafs storage could be enormous, more than local storage permits, and you could want to fault things in and do write-back caching. As I read the magic-folder README, I think one configures a dir that is fully synced. > It doesn't get WebDAV involved at all (a Twisted contributor tried to > contribute WebDAV support to Twisted once... sadly eventually the > effort fell over after *many* hundreds of hours and at least tens of > thousands of lines of Python code...). Instead it speaks to a > Tahoe-LAFS client node over the bespoke Tahoe-LAFS API (which *also* > involves tens of thousands of lines of Python code ;) but I could > imagine it using some kind of "Tahoe-LAFS client library" instead > someday. Sure, I only mentioned WebDAV because that is nextcloud's wire protocol. I did not mean that WebDAV was useful in the tahoe-lafs world, just an example of local sync to some protocol where the program writing would have *no idea* about the protocol or the remote filesystem, thus decoupling user program and filesystem, just like user programs are decoupled from knowing if the files are in fat32, ext4fs, BSD ufs2, nfs, coda, zfs, etc. >> I think you are suggesting integrating it direclty into libreoffice? I >> wonder how that's going to work, how libreoffice upstream would view >> that, or if you mean providing a way for an unmodified program to deal >> with a directory that is actually stored on tahoe-lafs. > > I didn't mean to suggest an implementation strategy with my last message - > just a user experience. Maybe a FUSE-like thing is the best way to > integrate with LibreOffice, and gets you all of the relevant features. If > all we're talking about is the "Save File" / "Open File" dialogs then the > filesystem is exactly the right abstraction because those things are tailor > built for *exactly* that interface. But perhaps you could have a deeper > integration - I don't know, I think answering that question would require > some product design work that hasn't been done yet (but I'd be interested > in exploring that direction, especially if other people want to explore it > too. And not just that direction - really any direction that leads to > Tahoe-LAFS satisfying more mainstream use-cases than it does now. There's > a *lot* of "technology" in Tahoe-LAFS. I think balancing that out with > more "product" would give a really significant bang-for-buck. Interesting thoughts about deeper integration. I don't immediately see how it would work but that could just be me. _______________________________________________ tahoe-dev mailing list tahoe-dev@lists.tahoe-lafs.org https://lists.tahoe-lafs.org/mailman/listinfo/tahoe-dev
