Links

• Mark Nottingham: 5 papers on protocol design
• Mark Baker: 5 papers on protocol design
• Bill de Hora: 5 papers on networked systems

• SRL2003-02 Mark Miller, Ka-Ping Yee, Jonathan S. Shapiro, Capability Myths Demolished - good article on ACLs vs Capabilities
• E Capability Desktop
• Secure Interaction Design (Ka-Ping Yee)
• Chandler Interaction (Drag and Drop) Spec

• Sharing Meeting Notes

Notes

Lisa made the following comment in the Sharing Meeting Notes:

(After the meeting, I thought some more and figured out that searches had better be smart enough that if a user name is searched for, and that name maps to a Contact, then the search ought to return every item cloud that the Contact has a bidirectional link to. Since in our Event content model assumed above, the Event has a bidrectional link to an attendee item and the attendee item has a bidirectional link to the contact, the search engine should be capable of following the links back to the Event and listing the Event as a match for that user. This is an interesting use case for searching in general. --Lisa )

Right now the query system is designed to return "sets" of items. If you want to get to items that are reachable from items in the result set, simple Python attribute access will suffice. Since the design of the repository doesn't support phyical layer clustering (due to the use of DBXML for literal attributes), there's no real advantage to being able to specify a bunch of clouds as a result set. In fact, if the items in the clouds are not actually used, then, you will have done a bunch of data transfer for no reason. Need to understand more what the requirement is here.

-- TedLeung - 19 Apr 2004