Notes
After re-reading this paper and a chat with Andi, I think that we have fewer of the problems described in the paper because we aren't remoting any Python code associated with items. We are still remoting the Repository (or more properly the private Store class) and this is going to suffer some of the problems described.
One other observation is that disconnected usage is indistinguishable from a network outage or remote crash (you can't assume that you'll get a notifiction telling you that a sharer has disconnected nicely), so disconnected operation falls squarely into the partial failure category.
External Addresses
One of the issues that we face with the whole external/2-level addressing situation is the existence of the parent/child hierarchy in the repostory. Today, the closest that we have to human readable names are respository paths, which are like directory paths in any hierarchical file system. The problem is that we're trying to discourage the use of hierarchy throughout Chandler. The Chandler store is really a sea (or soup) of objects, not a tree structured directory. There ought to be multiple entry points (roots) into the repository, we should be giving names to Items with semantically meaning refcollections (parent/child is in fact implemented using refcollections).
--
TedLeung - 22 Apr 2004