[tahoe-dev] zsh completer

[eurekafag]

I guess we have a misunderstanding here. I don't propose any changes
in tahoe itself. There are problems with mounting I already mentioned
before in this list and trac
(http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1138), don't know
whether they are fixed now because I have very little grid of 7 peers
which are always online. I'm about timeouts. When the node leaves
unexpectedly (due to power loss for example) it remains indicated as
active on other nodes. Not on all of them though but on some which
then begin to have access problems. Web-interface doesn't show a
single file because tahoe needs information from all connected nodes
but one of them doesn't respond while staying online-ghost. So it
waits and waits and waits, it can wait for minutes. That's almost not
a problem for web, you can just close the page and try later. But if
you mount it via sshfs, any process that tries to access mounted
directory gets D-state. So it freezes and can't be killed. At least
until you kill sshfs process. That's why mounting is not an option in
many cases, I don't want my browser freeze if I suddenly ran into this
situation. And remember that any node can lose connection at any time,
I can't do anything with it. That's how tahoe works.

Ok, enough about this. That's another topic I don't want to discuss
here. I talk only about zsh extension, not tahoe. Terminal won't
freeze because D-state won't happen (no long i/o waits because no
mounted filesystem which can cause it). It may hang while zsh tries to
complete (and calls `tahoe ls $comp_path` or such) but it's easily
interrupted with Ctrl-C without even losing entered command. That's
why I suggest making a completer instead of using a filesystem _at
least_ when you work with CLI. Of course, it won't help if you use
tahoe with any GUI application but I suppose *nix users here are the
most and they are more or less familiar terminals and console. So it'd
be quite useful. Not by any means I'm against mounting tahoe, please,
get me right. But sometimes it's just an overkill if you want to
upload a single file or just even bad if your peers have bad
connectivity. Again: it's neither a replacement nor change in tahoe.
It's a 3rd party extension or plugin. You name it. But it's the common
knowledge that the better 3rd-party support, the more use people get
of your software. No one needs spherical horse in vacuum (Russian
rede). Tahoe already has web and sftp support, it's time to make it
more useful with CLI! Especially when we have everything for this but
a wise completing.

2011/1/26 Greg Troxel <gdt at ir.bbn.com>:
>
> While I certainly agree with the notion of examining how tahoe and
> traditional filesystems differ and designing interfaces to bridge the
> gap, the current situation could be significantly improved by
> programming effort without having to solve those lofty issues.
>
> I'm sure most people on the list know the history, but for those new to
> Unix: originally there was just one filesystem, and then it was spiffed
> up to be the BSD fast file system with better properties, and then with
> NFS the vnode interface was introduced to decouple logical filesystem
> operations from a particular backend implementation.  Other filesystems
> (LFS on BSD, ext* on Linux, coda, HFS on mac) all use the vnode
> interface as the dominant mode.  My real point is that a VFS-based
> interface (and specifically FUSE) should be the standard approach to
> accessing tahoe to the point where there is fairly little need to access
> files through the other means; I view making direct mounting fully
> satisfactory as one of the top challenges.
>
> Tahoe certainly is based on capabailities, but it also has directories
> that map names to capabilities, and root aliases.  Ignoring mutable
> files for a moment, it's certainly sensible conceptually to mount a
> rootcap into a filesystem and have the OS treat that tree as accessible
> only to the uid that provided the rootcap in the mount.  Files/dirs
> accessed by RO caps should appear 0400/0500, and those accessed with RW
> caps 0600/0700.  sshfs/sftp at least mostly does this (I'm not 100%
> clear on the uid access rules, and suspect it varies by platform).)
>
> In some sense capabilities are like inode numbers (except of course that
> they are capabilities :-), but security properties aside they fit
> conceptually very well into the unix name/inode paradigm.  NFS has large
> numbers under the covers that are effectively hidden from users and the
> vnode interface.
>
> It's certainly a remaining challenge to figure out how to control the
> use of mutable vs immutable files, how to extract capabilities, and how
> to represent checking and health.   Arguably the vnode interface may
> need a new "get cap" control operation, but if that's what it needs we
> can just add it.
>
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>
>