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

James A. Donald jamesd at echeque.com
Mon Dec 28 15:22:17 PST 2009


Zooko Wilcox-O'Hearn wrote:
> The most successful filesystem products  
> try to hide the arbitrary graph layer as much a possible, where Tahoe- 
> LAFS tries to expose it as much as possible.
> 
> Further cause for concern: many Unix users, even "power users", try  
> to avoid the use of hardlinks whenever possible, considering them a  
> confusing and error-prone feature.
> 
> Pretty gloomy picture.  But there is hope: The Web!
> 
> Suppose instead of thinking of their Tahoe-LAFS-hosted files and  
> their Tahoe-LAFS directories as being part of a "folders-and- 
> documents" abstraction, and instead of them being part of a unixy  
> path-based "filesystem", they thought of them as a collection of web  
> pages which could have hyperlinks to one another.   Then there is no
> more "impedance mismatch" between the abstraction in the user's head  
> and the underlying graph structure.  No user is ever surprised that  
> multiple web pages can point to the same web page, or that following  
> a series of hyperlinks can take you in a circle.  No software  
> intended for the Web assumes that the set of web pages that it will  
> visit forms a perfectly hierarchical tree structure without cycles or  
> converging links.

"rm" however, tells the user that what "rm" is operating on can be 
thought of as a tree.  If it cannot be thought of as a tree, this
is a bug.

People are used to navigating arbitrary networks.  They are used to 
manipulating trees.  It is really hard to manipulate a network.

Some of my larger documents are networks, and all of them should be 
networks, and this makes navigating them easier, and manipulating them 
harder.  Arbitrary networks are inherently hard to manipulate.  This is 
not a user education issue, not a user mental model issue.  It is the 
way things really are.

To easily manipulate large numbers of objects, they have to be organized 
as trees.  This is done by making some links parental, and some links 
non parental, and the parental links form trees.  For the purpose of 
navigation, all links are alike.  For the purpose of manipulation, 
parent-child links are special.

Under the covers, if one is implementing a tree on top of an arbitrary 
graph, child objects have one and only one link to their parent object. 
    The parent has should have links to all its owned objects, but these 
links in the parent are merely a speed optimization.  If parent links to 
children are out of sync, need to be corrected from the link on the 
child object to the parent.  Thus the key element to make a network into 
a tree is a special kind of link, with one and only one link per owned 
object, pointing to the owner.


More information about the tahoe-dev mailing list