Accidentally sent this reply just to Greg... ---------- Forwarded message --------- From: Jean-Paul Calderone <exar...@twistedmatrix.com> Date: Thu, Aug 17, 2023 at 9:37 AM Subject: Re: Announcing tahoe-capabilities 0.1.0.0 To: Greg Troxel <g...@lexort.com>
On Wed, Aug 16, 2023 at 2:50 PM Greg Troxel <g...@lexort.com> wrote: > Jean-Paul Calderone <exar...@twistedmatrix.com> writes: > > > Looking slightly more broadly, I think it would be great to get > Tahoe-LAFS > > integrated with some applications that people actually use. I think the > > audience for "a command line tool you can use to securely upload and > > download individual files to a server you or your friends operate" is > > fairly small compared to an audience like "secure storage for your > > OpenOffice documents" or "secure storage for photos you take on your > > phone". I see these Haskell libraries as a first small step towards > > engaging with those larger audiences. > > Indeed, the interface is a big deal. > > I have been quiet partly because I'm doing other things, and partly > because my filesystem views are out of sync with mainstream tahoe-lafs > and expressing them was seeming non-constructive. But it's been years, > and I'll try to limit this to once/year. > The list is pretty quiet and the active developers have been trying to figure out how to increase the user base so I think any input you have will be quite welcome. :) > > 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. > > 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. 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. > > Overall this is a full-on unixhead view, coming from someone raised on > K&R C :-) > > When the UNIX philosophy works, it works great! > > There's another view, which is that tahoe-lafs is primarily suited to > backups, and that integrating it into bup or similar is a good path. > > 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. -Jean-Paul
_______________________________________________ tahoe-dev mailing list tahoe-dev@lists.tahoe-lafs.org https://lists.tahoe-lafs.org/mailman/listinfo/tahoe-dev
