Alternate "skeleton" for ExportableAddressesJun2004

This design is meant to show high contrast to the straw-man skeleton in the ExportableAddressesJun2004 page -- to show what kind of options we have in designing a WebDAV-compatible address space.

Hierarchy                                                                     Kind (if not a collection)
- [ ] Chandler content
    - [ ] RTFM account Inbox
    - [ ] OSAF mail Inbox
        - [ ] Msg336                                                      Email
        - [ ] Msg337
        - [ ] ...
    - [ ] OSAF mail design mailbox
    - [ ] OSAF mail dev mailbox
    - [ ] OSAF mail commit messages mailbox
    - [ ] All mail "from mitch" view                                      View
    - [ ] Personal calendar
        - [ ] Lunch with Brian                                            Event/appointment
    - [ ] Work calendar
    - [ ] Contacts
    - [ ] Tasks
    - [ ] Sharing knitting group stuff
        - [ ] Knitting convention                                         Event/appointment
        - [ ] Question about casting on                                   Email
        - [ ] Re: Question about casting on                               Email
        - [ ] Re: Question about casting on [2]                           Email

Links

• More from Kragen on capabilities: http://www.canonical.org/~kragen/3-sec-arch.html
  • Capabilities are hard to revoke - eg ATM cards and passwords
  • It's hard to remember a large # of capabilities -- doesn't principal identity usually serve as the gateway to being allowed to look up a capability?
  • ACLs are hard to delegate
  • Kragen says it's fairly easy to write a principal-based system on top of a capability system; difficult to do the opposite. I disagree. Xythos WebFile^? Server's read tickets to Web pages are a capability-based system with capabilities granted only by authorized users (http://www.watersprings.org/pub/id/draft-ito-dav-ticket-00.txt).

• http://cap-lore.com/CapTheory/ProtInf/Basic.html#a-(Economy-of-mechanism)-Keep-the-design
  • Economy of mechanism is like KISS: keep the design simple and small, particularly for protection mechanisms, to avoid design and implementation errors that result in unwanted access allowed.
  • Fail-safe defaults
  • Complete mediation

• A note on distributed Computing -- wow -- very good paper, distills much of what I've heard about NFS, MSDAIPP, etc.

Notes on Coda or "Disconnected Operation in a Distributed File System"

Single call cache invalidation

In Coda, cache invalidation is really only needed once -- the first time, after a file is cached, that the file is subsequently updated. After that, since the client may never need to get the same file, the server doesn't send any more cache invalidation notifications, and the client is removed from the notification list.

Later, when the client decides to update the resource again, the client updates the cache and re-subscribes for a single invalidation notification. This is a great savings if the user doesn't go back to the same file for a while -- many changes can take place with only one invalidation notification and cache update taking place.

However, that doesn't work as well for offline functioning -- when offline, a client has no opportunity to receive that invalidation notification, and when online, a client may wish to update cached copies every time a change notification arrives. I may want to refer to Mitch's calendar when on the train and still see events that were added in between the last time I looked at Mitch's calendar and the last time I was online. So for our design, I'm assuming that clients subscribe permanently to all change notifications, and synchronized information is updated aggressively.

For receiving change notifications for changes that occurred when offline, we have to figure out whether there's a proxy server involved. If we use XMPP, then an XMPP proxy server may be able to keep around the notification and deliver it when the client comes online finally.

Scalability

The design lessons for Coda may not work so well for the general case of Web replication (though I think they work fine for Chandler). "The scalability of the [AFS] architecture has been convincingly demonstrated: several installations have exceeded 1000 nodes." That should be enough for Chandler to follow the same patterns although we may want to define behavior in the upper limit. E.g. if we have subscriptions/notifications, we may want to top those out at 1000 or so -- once a Chandler repository that was installed as a "client" receives a certain # of different subscription destinations the engine stops accepting more subscriptions.

-- LisaDusseault - 20 Apr 2004

See also

Warning: Can't find topic Trash.PagesAboutAddressing