On Thu, Oct 1, 2009 at 3:28 PM, Joel Dietz <[email protected]> wrote: > <<This specification describes Google Wave conversation manifest document > schema and blip document schema>> > > Probably want 'describes the Google Wave conversation manifest document and > blip document schemas' or 'the Google Wave conversation manifest document > schema and the blip document schema.' Might get rid of 'Google Wave' as > well. > > <<which together define the Google Wave conversation model. This > application model...>> > > The conversation model is an application model? I don't understand what > this means without reading the rest of the document, which is probably not > what you want from an abstract. >
It refers to Application in the IETF sense: http://www.apps.ietf.org/ "tends to focus on protocols presented in user-oriented programs such as email and the web." > > <<Documents are subject to constraints expressed in schemas similar to XML > schemas.>> > > I think you mean, 'Documents are subject to similar constraints as those > expressed in XML schemas' > > <<The use of XML in this specification>> > > A bit odd. You just said that your document structure is 'reminiscent of > XML;' now you are saying it is XML. Am I missing something? > > <<That is, XML is used as a convenient model and implementations are free > to implement that model in the manner that is most convenient and > performant.>> > > Perhaps, 'but the conversation model can be implemented on a wave server in > the manner that...' > > Maybe 'efficient' instead of 'performant.' > > There is lots of awkwardness because the not-quite-XML-ness of the data underlying documents. I am working on a revision of the spec to address that, which will hopefully make that awkwardness go away. > <<Here is a short roadmap of upcoming changes:>> > > Perhaps include adding documentation for components missing documentation > in your roadmap, since it is mentioned in your previous para. Either that > or hire me to do it :P > > <<The blip schema expresses>> > > Previously, 'blip document schema.' Lack of consistency with respect to key > terms is a common problem in the protocol docs (I know, I know, I promised > to document this a few months ago). > > Will fix. (I thought I'd caught all of those). > <<This representation behaves in a much more natural way when two clients > concurrently edit overlapping regions of text. The document representation > may not correspond to the most natural semantic interpretation, but is > designed to behave most naturally under operational transformation.>> > > Perhaps, 'but is designed to easily accommodate operational > transformation.' > > <<The following terminology is used by this specification:>> > > Maybe these term definitions should be in a separate document common to all > protocol docs? > > The final structure of the (presumably large) set of documents that describe all of Wave will probably look different from what we have now, until then there will probably some repetition. > <<# conversation - an interpretation of a wavelet as a structured > collection of messages>> > > Just curious how you came up with this. Which came first, the conversation > or the wavelet? > > <<# reply - a thread that represents a reply to conversation material > appearing above it>> > > I would expect this to be called a 'reply thread.' > > <<A conversation wave is a forest of conversations>> > > Forest? > > You've got two conversations: > > *1:* > <conversation sort="m"> > > <blip id="b+a"> <!-- first message --> > > <thread id="3Fsd"> > > <blip id="b+aaa" /> <!-- indented reply to "b+a" --> > ... > > *2:* > > <conversation> > <blip id="b+a"> <!-- first and only message --> > </blip> > </conversation> > > > Seems odd that your empty blip is only one element in the first example > (e.g. <blip id="foo" /> ) and in the second two (e.g. <blip > id="bar"></blip>). > Yes, bad habits on my part from writing XML, all the representations should use a begin and end element. > > <<The value of the sort attribute is used to determine the order of peer > conversation elements by sorting on sort values lexicographically. >> > > I'm lost in the forest. Can you give an example as to what sort="m" would > do? > > Yes, I'll add an example > <<The "inline" attribute determines whether the thread is anchored inline > in the parent blip.>> > > Is there an anchor at a specific point in the blip or just within the blip > in general? > At a specific point in the blip. > > << > > An inline private reply, also has an anchor offset referring to the > replied-to blip. > > > <conversation > > sort="r" > > anchorWavelet="c+e8xA" > > anchorBlip="123" > > >> > > > shouldn't this also be: anchorBlip="b+123" ? > Yes, will fix. > > <<Each line is preceded with a "line" element. >> > > > Curious what the rationale was for marking lines at the beginning instead > of the end, or wrapping them (as with the p and BR tags in HTML). > > > There are attributes for the line element (undocumented at this point) that affect the display of the line, so it made more sense to have the line at the beginning. Whether those attributes stay there or get moved to attributes is still in flux, which is why neither of them are documented at this point. > <<Thus an inline reply's inline location is marked with a reply element.>> > > > Is this the same thing as the anchor? Would be nice to have an example... > > I'll add an example. > <<A wavelet is considered to be in a conversation view if it references, > via an anchorWavelet property, another wavelet in the conversation,>> > > 'A wavelet is considered to be in a conversation view if it references another > wavelet in the conversation via an anchorWavelet property' is simpler. > > Will fix. > <<If the thread is an inline reply an anchor element must first be > inserted in the replied to blip>> > > Either I'm missing something or the anchor element has never really been > explained. > > Yes, a description of the anchor element will be added. > <<Transform the blip's document to the empty document>> > > Maybe 'to [or into] an empty document' ? I'm not quite sure what this > means. > > Will fix to 'to an empty' > Loved the Douglas Adams bit. Hope this is helpful. > > Very much, thanks! -joe > Cheers, > > Jd > > > > > On Thu, Oct 1, 2009 at 11:53 AM, Dan Peterson <[email protected]> > wrote: > > Hey folks, > > > > Given the recent push to open up the preview of Google Wave to users > > ( > http://googleblog.blogspot.com/2009/09/surfs-up-wednesday-google-wave-update.html > ), > > we wanted to take a moment to provide an update on the overall federation > > protocol effort. > > > > Short summary: > > > > We're continuing to work to open up a server-to-server federation port on > > WaveSandbox.com, but, due to production pressures related to our recent > > preview release, we are now planning to enable it towards the end of > > October. We've also been working to provide more documentation around the > > wave model, and so we've produced a draft specification for the wave > > conversation model: <LINK> > > > > Getting deeper into the details: > > > > As a number of you in this forum have already noted, we've added support > for > > agents to FedOne. Agents are the underlying infrastructure for robots as > in > > the Google Wave APIs > > (http://code.google.com/apis/wave/extensions/robots/index.html). The > first > > agent we created was "Echoey" which proved useful for debugging > federation. > > As the name implies that whenever added to a wave will echo a response. > > Check it out at: > > > http://code.google.com/p/wave-protocol/source/browse/src/org/waveprotocol/wave/examples/fedone/agents/echo/Echo.java > . > > > > In order for us to be able to federate WaveSandbox.com we have updated > our > > production systems to support the operations as used in FedOne. This took > us > > a significant step closer to supporting federation. We expect to make a > few > > small changes to FedOne in order to allow it to federate with > > WaveSandbox.com. > > > > Please note that once we start federating WaveSandbox.com, this will be > an > > experimental service. This means that we will not have 100% uptime, and > will > > likely still contain bugs. We also expect that have to perform data > > migrations on waves and enhance the federation protocol to allow for more > > efficient signing of deltas. > > > > Beyond the changes listed in the Google Wave Conversation model roadmap, > the > > federation protocol will continue to change over the course of the coming > > months as well. We are working through some of the quirks in our > production > > system, including sunsetting some unnecessary (internal) operations, > > specifying the format of URIs, and improving ID generation in waves. > Given > > the cryptographic authentication measures in the federation protocol, > once a > > wave has been generated (and thus signed), it becomes impossible to > migrate > > its contents from one underlying format to another. In order to avoid > > trapping user data in obsolete formats, the federation port on > > wave.google.com is gated on many of the above items. > > > > The draft Google Wave Conversation Model specification mentioned above > goes > > into significant detail about the XML-like format of documents stored in > > wavelets. You will note that the FedOne client does not use the document > > schema as published above. We expect the FedOne client to only provide > > limited support for the new document schema initially. Nonetheless, we > > encourage you to inspect it as this is where we are heading. > > > > Please take a look at the new spec, and let us know what you think. > > > > Cheers, > > > > -Dan > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en -~----------~----~----~----~------~----~------~--~---
