[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