[Dev] Parcel namespaces and the schema API

Phillip J. Eby pje at telecommunity.com
Wed May 11 18:44:39 PDT 2005

At 03:26 PM 5/11/2005 -0700, John Anderson wrote:
>Thanks for correcting me on the fact that the majority of parcels don't 
>contain Kinds. After thinking about it more I think what I should have 
>said is that I suspect the majority of Items added to the repository are 
>Instances, not Kinds

I'd expect that, too.

>  -- today those Items happen to fall into a few parcels, e.g. 
> parcels/osaf/views. Kinds are spread out into more parcels.
>I think the distinction between Kinds and Instances makes sense (but not 
>the distinction between UI Items and non-UI Items).

The reason I make this distinction is that I believe (although I have not 
verified) that the vast majority of instances created in most parcels are 
UI-related.  The exceptions appear to mainly be wakeup callers and other 
relatively simple registrations that can conveniently be handled as part of 
the same Python module that e.g. defines the behavior of the wakeup caller.

Currently, parcel.xml format requires you to jump through a lot of 
pointless hoops to create UI components (or so it appears to me), because 
it's a general-purpose item creation format.  A UI-specific format could 
eliminate many of those hoops, even if it was still an XML format.

Of course, I don't have such a format to propose at this time, and the only 
change I've proposed so far to parcel.xml format is to deprecate the 
<namespace> tag, which is now no longer needed for any OSAF-provided 
parcels, and adds no value to non-OSAF parcels.  Apart from this, and the 
requirement that at least an __init__.py exist for a parcel, I don't 
propose we change anything about parcel.xml at the present time.

>I also agree with Morgen's comment that we need a way for Items to refer 
>to other Items and to me it seems like this shouldn't require a Python 
>module since it's data referring to other data, not code.

Sure.  Of course, in many cases the items will be best defined by a Python 
module (e.g. the wakeup caller case).  However, it's unlikely you'll need 
to refer to such items from other parcels.  Really, the main use case (as I 
understand it) for cross-parcel item references is to integrate UI 
components, which is another reason why a UI-specific format might be very 

In other words, if the use cases break down into "things most conveniently 
done in Python" and "things that are UI", then creating a format to support 
UI use cases better might be a good idea.

However, as a practical matter, any parcel that defines schema or scripts 
behavior of any kind is going to have to have Python modules; the burden of 
adding a zero-length __init__.py file to the directory of parcels that 
don't have any schema or scripting seems pretty minimal, considering that 
for some time to come, developer use cases for extending Chandler will 
generally be more involved than just creating some instances.

>Personally I don't care what format we use for getting Items into the 
>repository -- as long as it's easy to use and it only populates an initial 
>repository with data. It's also important to be able to export data in the 
>repository in a format that can be later imported -- and it's desirable if 
>that wasn't yet another format to learn.

I don't think that an import/export format is something that anybody will 
need to "learn" unless they are writing a program to read or write that 
format.  It just needs to be a functional format, and we already have one: 
repository XML aka "packs".  The repository already has code to read and 
write this format, so it would be a waste to create yet another format, or 
even to try to create an exporter that creates files in parcel.xml format.

>  This will come in handy some day when we're able to edit the Items in 
> the repository using the UI and be able to export them as parcels.


More information about the Dev mailing list