Carry over info from Wiki page
My delicious bookmarks page
http://del.icio.us/twleung also includes semi relevant links
Sharing and Replication Meeting
I've been curious about the case for doing repository / sharing under the repository layer boundary. I've been imagining that we would use item clouds (or more properly, templates associated with item clouds) to define serializations of those clouds. These serializations could be used for sharing (C2C [Chandler to Chandler] or C2O [Chandler to Other] ) or for import/export. Then the data movement part of the sharing problem consists of taking an item cloud and a serialization template and feeding those to an engine that performs the appropriate serialization. The results can then be fed to a data movement protocol (WebDAV, SOAP, Jabber, rsync, etc). This gets you the ability to move/copy items. In order to do true sharing, we need more than that, we need the ability to solve (either completely or partially - with a callout to a human) an n-way version merge problem. There is almost certainly a protocol that controls how this is done.
One thing that I learned today is that part of the case for doing sharing below the repository boundary includes:
- the ability to generate a very efficienct serialization based on use of the repository's internal version history for an item
- the ability to fit into the repository's transactional framework. Lisa noted that Coda found transactions essential to solving the disconnected filesystem problem.
- the ability to integrate with the existing state machine inside the repository -- This seems like a restatement of the preceding bullet point
Initial investigations into parser generators for doing string parser for the query language
I could write a recursive descent parser for the query language, but before I do that I want to at least look at what is available in the way of parser generators for Python.
--
TedLeung - 16 Apr 2004