r1 - 25 May 2004 - 13:35:00 - PieterHartsookYou are here: OSAF >  Projects Web  >  OsaFoundation > WestwoodDesign > HigherEdDeliverables20050105 > HigherEdCalendar > CalendarArchitectureDiagrams

Calendar Architecture

Note: I still need to run some of this by the architecture team, but this diagram might be useful to talk about some current thinking. I should be more clear about this by early next week. If nothing else, the terminology is subject to change.

Model of Chandler running on single user's PC

Calendar Architecture Open Issues

  • The Chandler client uses RAP to talk to its item store.
    • Like a CAP calendar store, a RAP server is an "item store"
    • Like CAP, RAP allows searches over the items using a query language
    • Like a CAP calendar store, a RAP item store is responsible for access control
  • In a Chandler workgroup scenario, "publishing" calendar information is handled through RAP. A Chandler client can browse other users' repositories if the user has the right permissions. For availability, a user can "replicate" part or all of their repository to a machine acting as a workgroup relay server.
  • If Chandler were to be a client to a CAP server, it would aggregate items with RAP and other data before making them available to the Chandler views.
  • Scheduling behavior (processing meeting invitations, creating replies, etc.) happens in the Chandler client (the calendar user agent). The Chandler "item scheduler" looks at iTIP-style objects and handles them.
  • The Chandler repository needs to accept iTIP objects via CAP for scheduling interoperability with other CAP calendar stores.

-- KatieCappsParlante - 28 Mar 2003

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r1 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.