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