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

David-Sarah Hopwood david-sarah at jacaranda.org
Fri Jan 1 19:14:02 UTC 2010


James A. Donald wrote:
> Chimpy McSimian IV, Esq. wrote:
>> 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. 
> 
> Summarizing what I said earlier:  Everyone is happy to browse arbitrary 
> graphs.  No one likes to manipulate arbitrary graphs.  Engineers are 
> barely OK manipulating directed acyclic graphs.  The rest of the 
> population are only going to manipulate trees, and if it is not a tree, 
> it is a bug.

A tree-structured filesystem is not implementable under the constraints
that apply to a distributed system like Tahoe that supports fine-grained
sharing of directories and files. As I said in response to Chimpy's post:

# Chimpy McSimian IV, Esq. wrote:
# > 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.
#
# This would be incompatible with supporting fine-grained sharing: if
# I send you a capability for a directory that I've created, you would
# not be able to link it into another directory that you created. This
# would be a severe regression in functionality that is relied on by
# many Tahoe users, not just "a few nerds". In any case, it's not
# even implementable -- there is no way of knowing, when a capability
# is linked into a directory, whether it has already been linked elsewhere.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20100101/de832ab2/attachment.asc>


More information about the tahoe-dev mailing list