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 helpful.
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.
Yes.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
