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

[James A. Donald]

James A. Donald wrote:
>> for sharing is browsing, rather than manipulation.

David-Sarah Hopwood wrote:
> "Browsing" is a user interface abstraction. "Sharing" means sharing
> references. They're not comparable.

Sharing should be done using an object that has the user interface 
characteristics of a Microsoft shortcut.  Shortcuts are cheap to drag, 
drop, and embed in messages.
>
> Manipulation (i.e. changing a mutable graph) has the same semantics and
> operates on the same structure, whether you do it with a browser interface,
> or a CLI interface, or programmatically. If cyclic links are supported
> (even if restricted to symlinks), then that structure is a graph,

Manipulating arbitrary graphs is hard.  Microsoft's solution is correct. 
  A subset of links that form a tree are treated differently for 
manipulation purposes.  All links (forming an arbitrary graph) are 
treated the same for browsing purposes.

> regardless of what is displayed by the user interface. In the distributed
> case where fine-grained sharing is supported, the structure *must* be a
> graph, again regardless of user interface.

It does not have to be manipulated as an arbitrary graph, and perhaps 
cannot be manipulated as an arbitrary graph.

Suppose objects are in the cloud.  Suppose a there is a storage cost 
against each object.  Objects can own other objects in which case the 
storage cost is charged against the owner, and ownership relationships 
form a tree, the root of the tree being an object that represents the user.

In that case the delete, copy and create relationships are necessarily 
treelike, necessarily work the way manipulation commands in Microsoft 
explore works, even though the browsable links may well form an 
arbitrary graph, as shortcuts in the Microsoft explorer do.

> It is simply incorrect to say that it is easier to manipulate trees than
> to manipulate directed graphs. Tree structures are not closed under the
> operations of adding or removing child links to another arbitrary node.

They are if we distinguish between shortcuts, which merely link, and 
child parent links.
> 
> Most file browsers show trees for one or both of the following reasons:

Microsoft explorer does not show trees.  It shows an arbitrary graph, 
and, for file manipulation purposes, distinguishes a subset of that 
graph that forms a tree.

> a) they're often descended from implementations in which the filesystem
>    was a tree. (This is why Vista's file browser breaks when the user
>    tries to browse a graph, for instance.)

I browse an arbitrary graph every few minutes.  Works fine for me. 
Microsoft has supported arbitrary graphs for a long time.

The reason file browsers distinguish a subset that forms a tree, is that 
manipulating arbitrary graphs is inherently hard, even though browsing 
arbitrary graphs is easy.