Andi is responsible for the API to the building blocks (XML format to load data)
We don't need all the 'tools', but we do need some minimal set
There's some disagreement about how big or small the 'schema of schemas' will be
Brian will work on formalizing the data model (schema of schemas, tools) in a 'top down' fashion, to meet up with Andi's 'bottom up' view from the repository
who's doing what?
After dev meeting, much discussion about the different layers, ownership, api
Before Andi leaves town (in 3 weeks), he has a plan to deliver:
XML representation for building blocks: item, itemref, container, etc.
Implement building blocks on top of ZODB
May work on a bit of schema of schemas, enough to bootstrap
John thinks we'll have more clarity if we work through an example: Katie will provide one in the calendar domain.
John will be working on a "hello world" example in parallel, to get his head around the problem and start on good developer documentation
we might not need namespaces, because items can always be refered to by UUID rather than by name
resolution: left this as an open issue for now
Unicode everywhere at the user level, not ascii
symbols -- used for python mapping -- ASCII strings with no spaces, etc.
Polyglot strings, most likely -- (dictionaries of translations, keyed by language)
any string, possibly -- (an attribute of type any string could have a value that was a unicode string, or a polyglot string, or a rich text string
more complex types of strings are allowed (all can be represented by ascii), but captured at a higher level (building blocks is unaware of them)
rich text strings should be represented in some platform independent way, rather than storing the different platform-specific rich text strings that one encounters on Linux and Windows and Mac
end user vs programmer
The end user wants malleable data, the ability to construct arbitrary views and do interesting searches. The programmer wants objects to use when writing code: some reliance on structure, easy persistence, etc. We've struggled with these two design goals, we've occasionally captured this tension as "item centric" vs "object centric". We could also refer to these two things as the "data model" and the "object system" respectively. It may be a good idea to formally separate attributes (on a given item) into end-user-visible-attributes and programmer-housekeeping-attributes, where there are different expectations for the different types.
We will only persist items and their attributes, not random python objects
We will try and represent a type as an Item
3rd parties being able to define their own types is a possible later feature, will not be addressed out of the gate.
If you delete an Item, is is truly gone?
weak deletion: delete the current version. Yes.
strong deletion: delete all versions, the data is not around if you're supoenaed. We may not implement versions at the repository level. No.
What's our relationship to RDF?
We want to be able to express our schema in some sort of RDF (import and export in that format), but it can be a general Chandler-centric RDF, not an RDF designed for interoperation with other apps in specific application domains
Chandler application level parcels may want to have their own RDF import/export tools, to express their data in a particular rdf schema (calendar, foaf, dublin core)
We do not aim to be a general triple store, capable of storing arbitrary RDF
will the kind item for "Contact" have the same UUID in every repository?
will the UUID be a tuple that includes (or encodes) the "home repository" of an item?
will different types of datastores each assign their own flavor of UUID?
will the client be able to assign its own UUIDs, or does it have to request them from the server?
resolution: client can make up its own new UUIDs to assign
UUIDs will be randomly generated 128-bit values
can you take two items that different UUIDs and merge them so that you end up with only a single item?
might be desirable from a user's point of view, but implementing this in a general way would be hard
can a user edit the Chandler PIM schema?
example: Joe adds a new "hair color" attribute definition to the "Contact" kind
resolution: NO, all the PIM Schema instances are read-only -- more generally, any schema instance should be read-only if there's ever python code written against it
can a user create their own sub-kind of "Contact" and add attributes to that?
creates lots of complexity when users start sharing items that come from schemas that were originally related but have been forked
this is a snake/dragon
doing this in a general way could end up being a research project
resolution: we recommend that any item version features should be implemented on a case-by-case basis up in the application parcel code, rather than having the repository offer any kind of ubiquitous general-purpose version mechanism for all items
we will definitely want to have local copies of items from foriegn data sources (like IMAP mail), in order to handle indexing and querying from within Chandler, and in order to work when off-line
we will definitely want to have local copies of items from other Chandler repositories, for example when a user has subscribed to something from somebody else's repository
this problem will probably end up belonging to whoever is doing replication -- we're going to leave it be for now
snakes and dragons
Sharing data, sharing schema
Schema editing, schema evolution
Query, indexing (we have some rough agreement, still to be worked out)
Versioning. Recommendation: implement this as an application feature, not a general repository feature.
Merge/Sync more than two repositories.
We declared victory (by changing the definition of victory). We have enough of a common picture to do individual work and meet back up again, so today's meeting was the last of the marathon series of six meetings.
create a formal representation of a proposed data model
arrange a meeting to present our progress and current thinking on the data model and repository
Start the Python implementation of the data model building blocks. The goal for the first week is to be able to present an XML based format to load items into Python memory and to save them back to XML. This week is the starting point of the implementation of the data model from an object persistence point of view.
Start working on the calendar part of the pim schema. Have an example ready for the group to walk through
Brian, Katie, John, Andi
Once Andi is in a good spot, meet up again to walk through Katie's example and catch up on Andi's latest thinking. Would be good to have a draft XML format, general proposal for building blocks.