[Chandler-dev] Re: Next steps: external information model

[Phillip J. Eby]

At 11:34 AM 9/8/2006 -0700, Ted Leung wrote:
>Ok,
>
>So I finally spent some quality time with <http:// 
>lists.osafoundation.org/pipermail/chandler-dev/2006-August/ 
>006692.html>.  In general this looks good to me, and the EIM looks
>especially good since we are going to have a relational database
>under the hood of Cosmo now.
>
>There are a few items from the open issues section of the proposal
>that I think that we should flesh out:
>
>1. It seems to me that we are going to want to do diffs in our
>pursuit of good sharing performance, so working out the key
>management section is probably important.   Note that I am not
>talking about the "Processing Diffs" section of the proposal, which
>has to do with diffs between versions of schemas.  I am talking about
>computing diffs of items to reduce the amount of data transmitted
>over the wire.

Actually, that *is* what the "processing diffs" section is about.  The idea 
is that when you transmit a field value of schema.NoChange, you can do so 
by omitting it from the transmission.

Regarding key management, it has occurred to me that a recordtype with a 
multi-field primary key could simply use parentheses in the arguments to 
denote this, e.g.::

     @sharing.recordtype("http://schemas.osafoundation.org/pim/contentitem/tags",
         item = itemrecord.itsUUID, tag = tag.itsUUID
     )
     def tagging((item, tag)):

Notice the extra () around the parameters.  So, we could say that the first 
positional argument is always the primary key.  The downsides to this 
approach are:

1. It's kind of obscure
2. You have to include the extra parentheses when creating records


>2. I'd like to see us try to address the "Type Information" issue as
>well, since one of the next (huge) steps for the Cosmo UI is to get
>away from being hard-coded to events.   If we are going to put in a
>new infrastructure for Cosmo UI, I'd prefer that we put in the
>correct one from the start.

As I mentioned on IRC, we can easily expand the API to include type 
information using keyword arguments to @sharing.recordtype, but of course 
we need to have a formal vocabulary for how types end up being specified, 
especially in the actual transmission format.

There are several basic type vocabularies that we could use to establish a 
type system:

* Python types
* Java types
* Repository types
* Relational types (e.g. SQL-92 et al)
* XML Schema types
* XML-RPC types
* CORBA/MOF types

Each approach has pros and cons.  Python or repository types are certainly 
convenient for Chandler, while Java and relational types would be more 
convenient for Cosmo.  The others are likely to be equally inconvenient for 
both.  :)