This Section is currently an outline only. I have included some paragraphs from the OSAF documentation on topics, which I think are important to be covered. This is however not finished yet.

I am also working my way through the Chandler-Wiki and other information to get an idea of what is already there, what needs to be changed and where to place functionality to extend, what Chandler has already got.

Any help & hints here will be highly appreciated� Please post any comments here or send them to bgroehl@snafu.de

General Integration

I imagine my Toolbox algorithms to be implemented in a fast and efficient way. C/C++ will probably best. The Viewer and the �glue� of how things are arranged and interact with the chandler environment will be probably Jungle.Python, wxPython or whatever is recommended for Chandler representation layer and integration.

Parcels

A parcel is an aggregate object that adds new functionality to Chandler. Jungle.Parcels are the main way of distributing Chandler extensions. Jungle.Parcels will be distributed in a single file which will be unpacked into possibly multiple files.

A parcel may contain Chandler data items (contacts, calendars, images, etc), plus Jungle.Python scripts to implement new types of views and agents, as well as version and dependency information, and cryptographic credentials. Chandler will be distributed with a few built-in parcels, but others can be downloaded from the Web or (eventually) shared using Chandler's sharing capabilities.

Data-Storage

Data in Chandler is stored on repositories on the user's local machine, on others' machines, and on shared resources such as servers. Instead of using a relational database data model, Chandler has a data model that looks more like what you would see in an associative database, or in an RDF schema. All the data in Chandler is represented in terms of items and attributes. Every email message is an item, and so is every calendar appointment, and every address book contact. New parcels will create new kinds of items.

Currently I am somewhat confused about the future role of zodb and Pyre (python repository) vs. Berkeley dbxml and Berkeley db for data-storage in Chandler.

@@@Maybe someone at OSAF can update me to the future strategy about zodb and Pyre

The Item Object is the fundamental building block of Chandler objects. It is the object from which almost all other end user-visible data objects inherit. Each item contains a set of attributes. Jungle.Attributes are different aspects or elements of an item. Some attributes have special semantics for certain types of items.

How to build a Taxonomy into Chandler

It makes sense to implement the taxonomic elements (nodes) as Chandler Jungle.Items. All items are stored in repositories. They can be shared and securely sent to one another. Jungle.Items have version histories, each of which can be accessed by a unique URI. Jungle.Items are related to each other through attributes. This URI might be used by the taxonomy to store the reference to a Chandler object.

There could be the also attribute "Category" in Users Jungle.Items (such as Email, Notes, Calendar and Documents), which may contain a pointer to the appropriate node in the users taxonomy. But remember, with the idea of �non-directional� pointers, this is completely optional. It may, however, be a useful integration into Chandlers native search capabilities. Corresponding documents might be found by �conventional search� against the appropriate URI to the taxonomy.

All functionality of Chandler repositories can be used to store and interface with the taxonomy. All functional aspects of the Chandler repositories could be utilized, such as data-management, import, export, security and authentication.

The schema could be even inherited by existing �standard� chandler objects and extended by the necessary descriptions.

Model-View Controller Framework

The Model View Controller (MVC) architecture separates the back-end data and application (model) from the front-end user-interface (view). The controller links the view and model. One big advantage of MVC is that it makes it easier to add a new front-end, for example, a Web or PDA interface for Chandler, without modifying the model. MVC is also useful in large applications because the data model can be developed largely independent of the user interface code.

Parcel-Integration

Chandler provides a rich API for implementing info-centric applications. The foundation of this is the Viewer Parcel API, which provides simple access to common services shared by all parcels. This architecture makes it relatively easy for programmers to create new parcels that can display new item types, or provide a specialized view on existing item types. Since parcels are written in Jungle.Python, they can be dynamically loaded, allowing the user to extend Chandler without having to re-compile. A Taxonomy Viewer would be probably integrated into chandler in the form of a parcel.

Core-Integration

I can see something, which is called �Attribute Indexer� in the Chandler Architecture Chart at: http://www.osafoundation.org/architecture.htm. I believe, this is the place, where a dynamic categorizer (the toolbox) would live. I cannot see today, if it will be a replacement or an addition to Chandler�s data-source services. I guess this has to be discussed.

@@@Anybody can help with �Attribute Indexer� in the Chandler Architecture?

Additionally there would be the need of an interface to the indexer and the toolbox, to control and change its behavior. This is something, which will impose the need for another parcel. Maybe it should be integrated altogether into the taxonomy-viewer.

Repository Service Interpreters

Chandler repositories may also be interesting data sources to other network clients, and so there may be other "services" which provide an interpretation of the repository. On the diagram we have drawn a service that allows CAP calendar clients to connect to the Chandler repository and a service that provides an RDF view of the item store. This might be also used to access the taxonomy of a chandler client.

Agent-Integration

An xml file and some optional Jungle.Python classes initially specify agents. Agents are persisted as items in the Chandler repository, which are created when their defining xml file is processed. All of the agent framework classes that require persistent data derive from the repository 'Item' class. In its main loop, an agent polls for notifications. When a notification is received, it efficiently determines the instructions referencing that notification, and gives them a chance to execute their conditions, and specifying actions to be performed. Finally, it executes the specified actions.

Notification

The Chandler Notification Manager provides an extensible notification system for high level events, like "message arriving" or "appointment reminder". Agents and parcels can declare and generate events that can be subscribed to by other parts of the system, which are notified when an event occurs, even across the network if necessary. We currently envision using it for database change notifications, too.

RDF

The Resource Description Framework (RDF) is a language for representing information about resources in the World Wide Web. It is particularly intended for representing metadata about Web resources, such as the title, author, and modification date of a Web page, copyright and licensing information about a Web document, or the availability schedule for some shared resource. However, by generalizing the concept of a "Web resource", RDF can also be used to represent information about things that can be identified on the Web, even when they cannot be directly retrieved on the Web. Examples include information about items available from on-line shopping facilities (e.g., information about specifications, prices, and availability), or the description of a Web user's preferences for information delivery.

RDF is intended for situations in which this information needs to be processed by applications, rather than being only displayed to people. RDF provides a common framework for expressing this information so it can be exchanged between applications without loss of meaning. Since it is a common framework, application designers can leverage the availability of common RDF parsers and processing tools. The ability to exchange information between different applications means that the information may be made available to applications other than those for which it was originally created.

RDF is based on the idea that the things being described have properties, which have values, and that resources can be described by making statements, similar to those above, that specify those properties and values. RDF uses a particular terminology for talking about the various parts of statements. Specifically, the part that identifies the thing the statement is about (the Web page in this example) is called the subject. The part that identifies the property or characteristic of the subject that the statement specifies (creator, creation-date, or language in these examples) is called the predicate, and the part that identifies the value of that property is called the object.

-- BernhardGroehl - 28 Dec 2003