I suggest you read the general verifiable federation white paper at http://www.waveprotocol.org/whitepapers/wave-protocol-verification . You may also want to read the other white papers an draft specs at http://www.waveprotocol.org/ .
Basically, as I understand it, each history hash is a hash of the previous history hash and the changes for the current version. You can check that two servers agree on the content of a version by comparing the hashes. On Mar 18, 3:15 am, Jae Lee <[email protected]> wrote: > Hi guys, it's been a while since my first submission, while waiting > for code review (4 weeks now), I've carried on testing on wave > creation notification to remote participant, blip > creation/modification(characters) by local/remote participant and its > notification in my wave-protocol > clonehttp://code.google.com/r/jlee119-wave-protocol/source/list > > While testing for blip modification by remote participant, I realised > I don't quite understand the meaning of history-hash of > hashed-version. Given scenario below > > request being > <iq type="set" id="oMSw9PZWHCMAAAAAAAAADQ==" from="wave.wonderland" > to="wave.bedroom"> > <pubsub xmlns="http://jabber.org/protocol/pubsub";> > <publish node="wavelet"> > <item> > <submit-request > xmlns="http://waveprotocol.org/protocol/0.2/waveserver";> > <delta > wavelet-name="wave://bedroom/w+nHxMnbx_r_Z-/conv+root"><![CDATA[CmwKGAgGEhQGEJP2kg90uKZc1TGWotpHs0ThxBIQYWxpY2VAd29uZGVybGFuZBo+GjwKCGIrbjBVVC1WEjAKAigBCgIoAQoCKAEKAigUChoSGCBJJ20gaW4gdGhlIHJhYmJpdCBob2xlLgoCKAESpwEKgAE0JCSuxuH6rBMhujKeVTH9nKJr/wrATD6POJmCogSIQA8F/a9qFaAwoIQ8H6HZQY2b4PRq7Cn1QDXyNppj32PPRTtWvBenCIPC414/bNuJyXYdaBaZQs4mZ1cW4PQOZ7vfGnUXu37jGxBOmAV+4vKX+fVHK0Kf/UUFz3OnHj691hIg2kunQeBb04Vy2j8jUN1hUWkm+dd0h126M5Ad6KhjZoUYAQ==]]></delta> > </submit-request> > </item> > </publish> > </pubsub> > </iq> > > response being > <iq type="result" id="oMSw9PZWHCMAAAAAAAAADQ==" from="wave.bedroom" > to="wave.wonderland"> > <pubsub xmlns="http://jabber.org/protocol/pubsub";> > <publish> > <item> > <submit-response > xmlns="http://waveprotocol.org/protocol/0.2/waveserver"; > application-timestamp="1268874762915" operations-applied="1"> > <hashed-version history-hash="xcS0RzQ/ANChJd1pp50skjWgwZs=" > version="7"/> > </submit-response> > </item> > </publish> > </pubsub> > </iq> > > What can I assert on submit-response other than its number of > operations applied and the resulting version? I couldn't figure out > what other information that I can extract out of history-hash.... any > help? > > thanks > J > > On Thu, Feb 18, 2010 at 7:55 PM, jlee <[email protected]> wrote: > > Hi guys, I've submitted my first attempt to write some high level > > functional tests. It is intended to be at upper level of Test Food > > Pyramid (http://c2.com/cgi/wiki$?TestFoodPyramid). > > > In my submission, I've got functional tests covering very basic wave > > creation, using full stack of fedone server. I've also got > > MultiHostWaveProvider to support testing inter WaveProvider > > communication. > > > Once I cover most of scenarios I want to be able to plug in third > > party wave provider and have a suite of functional tests to certify > > that it works with fedone implementation. > > > Before I could continue with more interesting behaviour of fedone > > server, I need code review onhttp://codereview.waveprotocol.org/39001/show > > > cheers > > J > > > -- > > 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 > > athttp://groups.google.com/group/wave-protocol?hl=en. -- 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.
