Part four of the Tour: I need to finish describing dynamics (started in part three), and get moving along to talk about the user interface (a later topic).

"Dynamics" is the name for Groove's transactional synchronisation stuff. This takes care of ensuring that commands for tools' engines are disseminated to each endpoint in a shared space, and processed in the right order. The result is that when you take a static view of a shared space, you're guaranteed to see a consistent state, and that this state will tend to be the same as the state on any other endpoint.

To freeze a shared space while you look at it (enumerating over records, for example), open a transaction (for read-only or read-write access): pTelespace.OpenTransaction(). When you commit() the transaction, any changes are applied and disseminated.

Looking at a dynamic view of the shared space (by listening to sequences of events from its engines), you'll see a more complex picture: if a transaction is interrupted halfway through processing and you open a "read" transaction to look at a snapshot, the database might need to unwind. If a transaction "from the past" arrives, the database will unwind, then roll forward again after applying the new transaction.

In the case of the tour, things could become difficult to track (were I using many transactions in the processing), but, it turns out, events pretty much arrive in the expected sequence. This is because I consciously minimised the number of "wrapped" transactions; generally, everything which happens is atomic and has no dependency to past or future events. So my propertylist listeners have an easy job. To catch any "futurity", I wrap a GUID inside each event, and maintain a reasonably-sized table of already-handled events. There's something to be said for belt-and-braces defensive programming, but in this case it turns out that's just overhead; it doesn't get used.

(It likely would, if the space ever had more than two members!)

In part two, I showed a couple of snippets of the tour script (the client script lives in groove/data/ToolData/groove.net/GrooveTour, if you care to dig in further). The script is a data-file containing structured code, which runs against events (That in itself is worth further discussion, sometime...!). Now, where do these events come from? They're wrappers around COM events fired by pieces of Groove (the EIS server, the workspace, the account, the telespace, or tools).

Much of the code at the server is simply providing nice, type-safe, script wrappers around these existing event services. In the tour, part of the ease-of-use comes from choosing an appropriate level for these wrappers; and part comes from providing a "tool" context object with each event, which immediately puts you in the right place. At the server script there's also always a "chat" object which provides an interface to the chat tool. In many ways (not least for debugging), chat is the commandline.