Map of Chandler

This document is a brief introduction to Chandler's technology stack, noting various other open source technologies that we're building on and introducing some terminology that is important to know to participate in technical discussions about Chandler. The Chandler technology stack at a glance, as of the 0.3 release:

Python

Although it is not in the diagram, Python is a key piece of Chandler's technology stack. Chandler is distributed with a full Python installation; more for user convenience than because we've substantially altered Python. We're currently having a spirited debate about whether or not including Python in the distribution this way makes sense on all platforms; we're exploring various alternatives. We're currently using Python 2.3.2; generally you should be able to rely on standard Python 2.3 documentation.

wxWidgets

Creating a first class application on Macintosh, Linux, and Windows is one of OSAF's top priorities. We're using wxWidgets as our cross platform GUI framework, in particular the wxPython bindings. We chose wxWidgets because we wanted a native experience on each platform under one abstraction, with the option of writing platform specific code when necessary. That said, the OS X port is new and still needs a lot of work. We're committed to working with the wxWidgets and wxPython team to contribute to wxWidgets on all three platforms. We're using wxWidgets 2.4.2 as of the 0.3 release, but hope to transition to 2.5 soon after the release.

Repository

Chandler's repository and its relationship to data will be one of its signature interesting features. This is not your father's relational database! Inspired by RDF and associative databases, we put a lot of thought into using a flexible data model (and a lot of work into an implementation of that data model). Chandler's repository stores and retrieves persistent objects called Items. One of the interesting features of the data model is that schema information is stored similarly to all other data; Kinds and Attributes are types of Items. For a glimpse at the data model and the repository in more detail, check out the Repository Busy Developers Guide and this intro to the repository. The repository itself is implemented on top of Sleepycat's dbxml and Berkeley DB. We've also integrated Lucene, to use as a full text search engine. More information on the repository project can be found at Repository Framework.

Parcels

Parcels are Chandler's units of modularity and extensibility. Outside of the core subsystems, most of Chandler is written in parcels. Third parties will be able to extend Chandler by writing their own parcels. The foundation of our data driven application, parcels contain a set of Items that get loaded into the repository. A parcel is not a place that the user visits in the UI, although the parcel might define Items that are used to construct the UI (Blocks, Views, Events and Queries). A parcel might include Kinds and Attributes that define a schema, UI elements, agent items, even user data items. A parcel might also include python code, images, and other resources, referred to by the Items in the parcel. More information about parcels can be found in the Extending Chandler document.

Application

When we talk about the application, we are referring to both the base of the Chandler application and all of the parcels that get loaded into the repository. The base of the Chandler application creates a wxWidgets application, displays the splash screen, loads the repository, sets up a few global variables, loads all of the parcels, and performs various other initialization chores. Outside of this boostrapping and initialization, most of the application is implemented with parcels. A few of the parcels that Chandler currently contains are described below. Application Project^? is the home page for status about the application in general.

Content Model Parcels

The Content Model is the data model for what we think of as the user's "content" in Chandler: Calendar Events, Contacts, Tasks, Notes, Mail Messages, etc. Most of the content model is PIM related, but one could imagine that third parties might define new types of items: MP3s, documents, etc. We auto generate documentation for schema items from all parcels -- a good way to explore the current state of the content model.

CPIA Framework (Blocks Parcel)

The Chandler Presentation and Interaction Architecture is a data driven UI framework used to build Chandler views. CPIA is not designed to be a general purpose UI toolkit (we have wxWidgets for that purpose), but is designed to operate at a higher level to build data driven applications on top of the Chandler repository. The framework defines Blocks and Events as basic building blocks. These elements, along with repository Queries, can be used to build Views. A View is a self contained UI element that describes layout information for the view (Blocks), information about interaction with other views (Events), and knowledge about how to populate the view with data from the repository (Queries). Because they are Items, Views can be shared, persisted to the repository, customized, etc. A major goal of the 0.3 release was to use CPIA for Chandler's UI, to transition away from the old "viewer parcel" model. Although we have indeed hit that goal, CPIA is still very much in the middle of development. For more information on CPIA, check out CPIA 0.3 status and this example.

Notification and Agent Framework Parcels

The Notification Framework and the Agent Framework^? are two pieces of the Chandler infrastructure, implemented as parcels. The notification framework is used heavily by CPIA events. We're also using the notification framework for repository notifications to CPIA blocks.

Views

Although Views might be created dynamically, Chandler starts up with an initial set of Views. For the 0.3 release, the design team prepared a target for the apps team: ZeroPointThreeUI. We expect this UI to grow and change substantially, perhaps radically, as we iterate towards Chandler's eventual design. Our starting point:

• Chrome The chrome view (or "main" view or frame) describes the outer layout of Chandler, including a navigation bar and a sidebar. The chrome view currently displays one sub-view (or content view) at a time. Eventually the chrome will be able to display tabbed sub-views. When chandler starts up, this sub-view view is an "About Chandler" view, implemented with an HTML block. Note that the design team has been calling this "Chrome" and the apps team has been calling this frame the "Main View" -- we'll get the terminology worked out soon.
• Mixed, Calendar, Contacts, Notes Views of the user's data: contacts, calendar events, and notes. In particular, the mixed view was added because we know we want to break down the "silos" of traditional PIM applications: we can see different kinds of data in the same view. We wanted to start experimenting with implementing such a view in CPIA.

The next set of views is intended more for developers than for end users:

• Repository Enables the user to browse the contents of the repository.
• Block Demo A place to demonstrate various CPIA blocks.

Last but not least, we migrated the ZaoBao code from the first release of Chandler. Although RSS functionality is not one of Chandler's primary goals for the 1.0 release, we thought it would make a good example to push CPIA before we had a real design ready:

• ZaoBao ZaoBao is a set of views that display RSS items loaded by Chandler. We think of this view as an example view, more like a 3rd party view. ZaoBao also let us experiment with agents and threads.

These Views are all defined in parcels, as are all of the other items that get loaded into the Chandler repository the first time Chandler starts. Third parties will be able to define new Views, as well as other types of items in third party parcels.

Custom parcels

As mentioned above, third parties will be able to extend chandler by writing parcels. These parcels might define Kinds and Attributes, Views, or even implement new Blocks. An MP3 parcel, for example, might contain all of these types of items. As Chandler matures, one could imagine different kinds of items that a parcel might define; "spell checkers" is one example that we've mentioned before. We expect to add a framework to "register" such items with Chandler, so that they can be discovered. We have not yet implemented all of the infrastructure necessary for people to write such 3rd party parcels.

We've come to the end of our brief tour of Chandler's technology stack. One other map that might be useful to developers is a short explanation of the placement of Items in the repository...

Map of Repository Contents

When you load Chandler for the first time, if you take a peek at the Repository view, you'll notice it has this structure:

   //userdata/contentitems/*
             /zaobaoitems/*
   //Schema/core/*
   //parcels/OSAF/contentmodel/*
                 /examples/*
                 /framework/*
                 /views/*
   //Packs/*

The application's repository currently has four roots: userdata, Schema, parcels, and Packs. Every item in the repository needs a location, and this is the structure we are currently using for placing items in the repository. Note that this structure is important in the sense that every item has a well known name, but has no other semantic meaning.

• userdata is meant to be the location of the user's data, in particular the user's "content items": calendar events, tasks, email messages, notes, etc. We currently put the zaobao items in a different namespace/container, as a temporary workaround to a problem with conflicts between threads in Chandler. We expect this problem to be resolved very soon after 0.3, when the repository gets more sophisticated merging features. After the problem is resolved, we will put zaobao items in the same place.
• Schema is the location of the repository's core schema, the items that the repository creates as it bootstraps into being. Examples: Kind, Attribute, etc.
• parcels is the location of all of Chandler's parcels. The path of the parcel's container is currently considered its "namespace". The namespace of each parcel reflects the directory structure under Chandler/parcels. We chose this convention to avoid managing duplicate hierarchies. Most of these parcels are described above.

• Packs is the location of "packs". Packs are not unlike parcels, the repository's own mechanism for loading groups of items. The core schema pack is currently the only pack loaded by the application.

-- KatieCappsParlante - 23 Feb 2004