Phillip J. Eby wrote:
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.
The only reason we have a lot of UI Items is because we've been focusing on UI. Suppose you wrote a parcel that implemented some non-UI functionality -- it would need a bunch of non-UI Items. One of the beauties of our system is that you can create any kind of Item -- and that the Item creation format isn't hard coded to specific types of Items. I'm sure we could come up with a format that lets you create any kind of Item without having to jump through lots of pointless hoops like we do today.
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.
In the long run I think it makes alot of sense to create a parcel by hand, bring it into Chandler, edit with tools in the UI, export it back to a parcel, tweek the parcel by hand, distribute the parcel to the world. It's unfortunate if you end up having to learn two slightly different parcel format to do this.
I've used systems like this before and it's really very handy. It opens up the possibility of editing data to non-programmers and still allows programmers to have complete control.
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
