[Cosmo-dev] simplifying eimml

[Brian Moseley]

On 12/1/06, Phillip J. Eby <pje at telecommunity.com> wrote:

> They would just be other EIM records.  Think of it as being like the system
> tables in a relational database server, that contain rows describing the
> columns of the tables in that database.  :)

right, but what would they actually look like?

what would a record look like that describes the columns of the event
record type? i'd need to be able to look at that record and say "ok
the first field in the event record is the uuid and it's a text value
with length 32". also, i'd need to be able to choose the one system
record that describes the event record type out of the entire set of
system records

maybe something like this:

<column:record>
  <column:recordType>event</column:recordType>
  <column:name>uuid</column:name>
  <column:datatype>text</column:datatype>
  <column:len>32</column:len>
</column:record>

of course this turns into ten records to describe just the event
record type. would we send these records on every pub/sub/update/sync
request, even if there is only one (or zero) event record?

and then we'd have to process this stuff on every request just to
figure out how to process the regular records. maybe not such a big
deal for single-user chandler that syncs once an hour, but definitely
a big deal for cosmo.

well, you might say, we could do some sort of version negotiation so
that these records are only included or processed if the client and
server have different understandings of the event schema. but that's
yet another chunk of complexity we have to design/test/debug.

so yea, we definitely don't have time for anything like this in 0.6,
and i dn't think it's a good idea for the future either.

> Yes.  There is no requirement that EIM records in the general case contain
> any UUIDs at all, let alone ones that are in any way related to the item
> identifier.

that is true, but that doesn't mean the representation of a record in
xml has to exactly match the representation in memory. we can require
the eimml processor to make sure that the in memory representation has
the uid field that it needs, even if that value is serialized in xml
as part of the batch element rather than the record element.

if i understand you correctly, you want the eimml processor to be as
stupid as possible, even if means that the serialization of a full
record set is more verbose and denormalized than it really needs to
be.

> We don't lose it; we're just *batching* sets of records.  For all practical
> purposes, the "envelope identifier" could just as well be some kind of hash
> code that divides the record keyspace in a meaningful way, so we don't have
> to load records for the entire collection when doing diffs.

ok, then let's name the element "batch" rather than "item" or "item
state" or "envelope". that seems to describe the intent of the
grouping element most precisely.