[tahoe-dev] down with filesystems! up with the web! -- Re: [tahoe-lafs] #776: users are confused by "tahoe rm"

Chimpy McSimian IV, Esq. mr.monkey at gmail.com
Thu Dec 31 11:21:12 PST 2009


I don't understand the problem. To me, filesystems and the web are
fundamentally different. While they are both built using, in part, the
same data structure (directed, cyclic-by-various-means graphs), the
similarities seem to end there.

Web:

* many object formats
* vertices embedded in files
* vertices encoded in a single document format; i.e. non-HTML object
must be leaf nodes

Filesystem:

* many object formats
* object names are vertices
* vertices not encoded in documents; or, not particularly powerfully

Also, I think users *do* understand filesystems pretty well. In fact,
Gmail confused some users by presenting "tags" instead of "folders" --
even though tags are more a more general UI mechanism than folders
("search instead of sort; tags enhance search to provide
sort-equivalence"). You can implement tags *as* folders (imagine the
symlink /mail/tags/noodles -->
/mail/messages/cur/1262234884.M140249P6756.strawberry.noncombatant.org,W=1842:2,S
to see what I mean). This Google blog post is a response to people who
were expecting folders:

http://googlesystem.blogspot.com/2009/02/gmail-adds-folders-by-improving-label.html

If anything, it sounds like you should stick with exposing a tree
structure to users. Arguably, you could leave out any capability for a
many-to-one name --> object relationship (i.e. no symlinks or multiple
hard links), and disappoint only a few nerds while avoiding confusing
the majority of users. I'd argue that existing filesystems have it
right: provide either or both of symlinks and multiple hard links, and
only expose them to users sparingly if at all, while taking advantage
of them in application implementation (like how mail servers use
Maildir).


More information about the tahoe-dev mailing list