Hi Michael, I can answer that new question quickly.
If you're looking for an object model that has the same structure as a DOM (i.e., element nodes, text nodes, etc), then you won't find it on the server. Saying that the documents are "annotated XML" is an abstract description that conveys the kind of information stored in documents. While any document *can* be represented as XML and a set of annotations, that is not the form of the object model used by the server to represent a document. Instead, the server uses a much more efficient representation: i.e., it represents a document as an operation. This is because there is nothing on the server that needs to inspect the DOM form of a document. All the server does is apply ops, and provide representations of entire documents at different points in history (as an op). On the client, however, there are use cases that wants a DOM style object model for the representation of a document. This is exposed by the MutableDocument type. MutableDocument is generic, and has a concrete version that covers most use cases, called Document. The API is not a w3c DOM API, but is instead something that is essentially equivalent to it that allows much more efficient implementations and is also more typesafe. Instead of an API like element.appendChild(node), you get document.appendChild(element, node). But apart from that stylistic difference, there's the DOM representation of a document. -Dave On Mon, Jan 9, 2012 at 5:00 AM, Michael MacFadden < michael.macfad...@gmail.com> wrote: > Thank, > > I think I have figured out everything except for my question #1, by > debugging the code. Still looking for an answer for that one. > > I do have a new question. It has been said that the conversation model > (specifically the blip documents) are represented as "annotated" XML > documents. I haven't actually seen an example of a blip document with > annotations. Nor does it appear that the documents actually live anywhere > as XML. I see the object model of document floating around, and I see that > they are serialized in a semi binary format to the delta file store, but I > haven't actually seen them represented as annotated XML anywhere. > > Mainly I am interested in seeing an example of a blip document represented > as XML with annotations. Does this exist anywhere? > > ~Michael > > On Jan 7, 2012, at 10:57 PM, Alex North wrote: > > > Hi Michael, > > > > I've been intending to send you some good answers to these questions. I'm > > just struggling to carve out the time to drag up the memories and give > you > > the info you need. But I still intend to! Hassle me, and feel free to > send > > more questions as they come up. > > > > On Wed, Dec 28, 2011 at 3:24 AM, Michael MacFadden < > > michael.macfad...@gmail.com> wrote: > > > >> All, > >> > >> I have been trying to dig in to the CC and OT concept in wave, so I can > >> start to work on that section of the code. It seems like we have been > >> focusing on the UI and I want to make sure we have coverage in the CC > >> stack. I have read all of the OT literature, so I am fairly well > versed in > >> OT in general, but some of the specifics of the WaiB implementation are > a > >> little fuzzy. > >> > >> Right now I am working on understanding composition and how we infer the > >> servers path. I have a few questions. > >> > >> 1) In order to compose operations I assume they don't have to have the > >> same document width (how could they for successive inserts for example), > >> but I assume they would need to span the same line? Is that right? In > >> other words you wouldn't compose operations from one paragraph with > >> operations from another? Is the desire to compose one of the driving > >> reasons for the retain operation? > >> > >> > >> 2) When we send out "first" operation over to the server and we are in a > >> holding pattern buffering client operations, are these operations always > >> composed together and then sent over as a single operation when we get > the > >> ACK from the server. It seems like we can only send one operation to > the > >> server at a time, however the on line material implies that when we get > and > >> ACK we send over ALL buffered operations. This seems to be > contradictory. > >> If we have buffered 4 operations, it seems like we can send all of them > as > >> four individual operations. > >> > >> > >> 3) Is there a run down of how the CurrencyControl class does point #2 > >> anywhere. I see the unacknowledged, the inferredServerPath, and the > >> clientOperationsQueue objects and get a lose impression of how these are > >> managed but any help with regard to incoming server operations while we > >> have an operation in flight would be appreciated. Specifically what > >> transformations are performed on which object structures when we get a > new > >> operation form there server, and where / when is composition happening. > >> > >> > >> 4) How exactly are the hashed versions designed? There seems to be a > >> monotonic scalar version number and a hash? I want to make sure I > >> understand how both are generated and how both are used. > >> > >> > >> If any of this is well documented, please let me know where I could find > >> it. If it is not, I would volunteer to document this as I work through > it. > >> Thanks in advance. > >> > >> Michael > >
