[Dev] Parcel namespaces and the schema API

[John Anderson]

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.
>