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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
