.4 Addressing Summary

Design philosophy

Chandler users should feel like they are working within the Chandler paradigm of items and collections, not a file-system of paradigm of hierarchically organized files. (Items are richly interconnected; membership in collections is fluid; Items exist in multiple collections at once; deleting a collection does not delete its content items; etc.) More specific requirements can be found here: DesignRequirementsForAddressesJun2004.

One of the major consequences of this goal is that Chandler developers do not choose a particular address hierarchy for the user's data (contacts, calendar events, item collections, etc.) Similarly, the application does not force users to create an address hierarchy for their data. The user interface may display data in hierarchies, lists, or webs at runtime for the user to browse. The user interface code would make use of queries, references between items, and item collections -- not hierarchical addresses. Another consequence is that if Chandler displays a "link" to an item, it is not using a hierarchical address based on some categorization to internally represent the link. Chandler may use a uuid for this purpose, or more likely a reference between one repository item and another.

Repository API changes

We are no longer going to use the "repository path" as an item's address, instead we will use modified apis for attribute based addressing.

• We had been using the concept of the "repository path" as a kind of address: an item's parent/child relationship determines its path, and an item has one and only one repository path. We decided not to use the repository path as an item's "address", but instead to think of the repository path as a lower level construct. Higher level clients of the repository no longer need to specify the parent/name pair that establish the path for the item, this should be handled for the client automatically.
• Client code will use ref-collection based paths for addresses. Items can have multiple addresses, or no address. Items do not need to specify an address in their constructors. Because we think there will be one most commonly used address space, ideally the api would have a default ref-collection path.

Address spaces in Chandler

The current proposal is that we have one address space used by Chandler. Its worth noting that we have essentially 4 different categories of items, we'll discuss each one in turn.

• Core repository items The repository defines a few core fundamental building blocks of the data model, including Item, Kind, and Attribute. These items have one well known address.
• Parcel items These items are created by parcels. They may in some sense be considered "read only" items -- in spirit they should not be altered during Chandler's execution. These items are defined by developers as they are coding. These items are often Kinds and Attributes. Sometimes parcels create instance data that Chandler might use the first time it runs: the Block data that describes the initial layout of the application, for example. This out-of-the-box data is copied to the user's space, where it is modified as the user interacts with the application. Parcel items have a hierarchical address that reflects the hierarchy of the parcels in the filesystem. Parcels may also publish a flatter address space for some items, for the convenience of client code.
• User content items These items constitute what most users will think of as their data: contacts, email messages, notes, calendar events, mp3 metadata, etc. Item collections are also considered user content items. These items do not need addresses locally. To meet the design requirements, we will usually find these items with queries, via references from other items, or by uuid.
• User application data Instances of views, blocks, and tasks are representative examples of items in this category. These items persist the state of the application layout and other application preferences. Initial versions of these items may be defined in parcels and then copied to the "user" space. A few of these items may need well known addresses: the block instance that functions as the top of the tree of blocks that defines the application layout, perhaps other singletons with specific functions.

We've contemplated other address spaces. We may create separate "exportable" address spaces for interoperability requirements. One could imagine a separate address space for the tree of blocks, although we currently have no definite plans to do this.

To do in .5

• Addressing API definition
• Use addressing api in the parcel loader (and copy ootb instance data to "user space")
• Use addressing api in the content model (and create a new idiom for content model python code)

To do after .5

• We did not fully tackle interoperability requirements or "exportable" addresses that might be necessary for interoperability. We believe the repository primitives are flexible enough that we have the tools to tackle this once we understand the requirements. For example, we may need to create a pretty and/or hierarchical address space for user content items for non-chandler clients, or for out of band references to items.

References

• Information about the current parcel loader: ParcelManager
• Brian's original list of possible requirements: CandidateDesignRequirementsForAddresses
• Andi's repository changes: http://lists.osafoundation.org/pipermail/dev/2004-May/001475.html
• Ted's notes on the data model api: TedLeung20040528
• Lisa's original proposal for ExportableAddressesJun2004
• Katie's notes on addressing and the application: KatieParlante20040514
• PagesAboutAddressing^?

-- KatieCappsParlante - 06 Jul 2004