We have released the first, small part of the Google Wave codebase together with a prototype implementation of a federated wave server and lightweight text client under the Apache 2.0 license. Please see the Wave Protocol project on Google Code (http://code.google.com/p/wave-protocol).
The release includes the wave data model, including the operations and the operational transformation algorithm. The released version is a close copy of our production code, and is in fact an iteration beyond what is currently running on WaveSandbox (we are working to catch up). Please note that all the code is still under active development and we do expect to make modifications to it, especially in the short term.
We have updated the documentation to reflect these new operations. As you probably know, the Operational Transformation (OT) code is the heart and soul of Google Wave's collaboration - it makes it possible for users to have the highly collaborative experience of wave. OT is part of a concurrency control (CC) algorithm that is responsible for ensuring wave clients can optimistically modify documents locally yet keep in sync with the canonical state of a wave on a server and that all clients will converge on the canonical state of a wave eventually (when everyone stops typing). In a federated system, it is critical that each wave provider manage the operation stream consistently, otherwise convergence cannot be guaranteed. This means it is highly recommended that anyone attempting to federate waves should exactly match the CC functionality of every other wave server. We believe this is easiest if our released code is used. We will be releasing a test and verification suite for those who'd like to do their own implementation (e.g. for porting the code to other languages), but we cannot put a date on that yet. The OT code as is now released is not quite complete and we hope to add the missing bits soon. However, as it stands it will do a lot of the concurrent editing that is inherent to wave.
The wave model code is a simplified version of our production code and is tied to the OT code. This code will evolve into the shared codebase (that we'll use and we hope others will too).
Source code under "FedOne" is the prototype wave server with federation support and a "toy" text client. The wave server is not a production-quality implementation (for example it currently keeps all wavelets' state in memory only!), but may serve as a foundation for one. At this time its main function is to provide an executable spec for how to "speak" wave federation, and as a good starting point for people to develop their own servers. We intend to expand the code base, but at this point are not sure of exactly how far. (And a 'heads up': a few features necessary for correct security support need to be fixed in the next few days).
The architecture of the wave server, federation host, and federation remote closely mimic the way our production servers work. Please see the online documentation for a description of the wave architecture. (http://www.waveprotocol.org).
The text client was included to show how a client may interact with the server. The client/server protocol is very simple and for illustrative purposes only. The client as implemented does not do full OT - it sends simple updates containing a line of entered text to the server to apply as a paragraph. There is no reason why the client could not be extended to use the full OT code, we merely chose to implement something slightly easier, and also show how one might "talk wave" without having OT in the client. You will note the interesting design of the client's inbox - it's sent as a live updating wave. This is an experiment in the "everything's a wave" paradigm. The client/server protocol is not intended as a standard at this point. In the future, we hope to figure out (with help from the community) how we may get to some standardization.
We have started up federated wave servers on acmewave.com and initech-corp.com. You can go ahead and connect to them. Note, however, that we don't have any users on those servers, so there won't be anyone to chat to right now. (We might add a robot that chats with remote participants, or maybe someone in this forum could write one and tell us about it... :) You can, of course, bring up your own instances and exchange details here on the forum, allowing you to federate.
Next, we will work to get our own system using the new OT and get federation supported for wavesandbox.com (and then wave.google.com), hopefully we'll do so by the September 30th extended preview, but note that it's a stretch goal.
We hope to see some really cool implementations based on the released code and we're looking forward to federating your waves come September 30th.
Excellent news! Great work and please pass my congratulations along to
the entire Wave team.
I'll also offer my opinion that I believe that having that test suite
soon is of critical importance to making sure that, as you say, all
Wave server providers are providing the same and latest up-to-date
protocol support.
Because Google (very, very smartly, IMHO) chose to use XMPP (and I
noticed in the latest Wave protocol version to use XEP-60 PubSub -
very good choice), that there are a load of XMPP server vendors out
there. All of the major players are using XMPP servers for their
collaboration products: Sun, Oracle, HP, IBM - both Lotus and non-
Lotus, Cisco (Jabber Inc.), etc. etc and the list goes on and on.
Therefore, it will be easy for these folks to add Wave protocol
support to their products. This makes Wave Protocol adoption almost
frictionless.
Of course, those of us 'in the market' for a Wave Server to install
inside & outside of our corporate firewalls will want to make sure
that the Wave Server we're buying (or the XMPP server we've already
bought that is getting a "Wave upgrade") is fully 'protocol compliant'
and that it properly implements the CC functionality as per Google's
specification. The only way we'll know that is if the product is
passing that test suite. You may even want to come up with a 'Wave
Inside' branding effort for XMPP servers that pass the full Wave test
suite (but I'll leave that to your marketing folks :-) ).
Therefore, I'm giving a big '+1' to the test suite :-)
Cheers,
- Bill
On Jul 24, 5:15 pm, Jochen Bekmann <joc...@google.com> wrote:
> .....
> We will be releasing a test
> and verification suite for those who'd like to do their own
> implementation (e.g. for porting the code to other languages), but we
> cannot put a date on that yet.
> .....
> Jochen Bekmann
> Software Engineer, Google Wave
Thanks for the kind words Bill. It's also worth noting that the
decision to use the XMPP Component Protocol means we can plug into an
existing XMPP system, without having to set up a new system, firewall
holes &c.
On Fri, Jul 24, 2009 at 18:15, bedney<bed...@technicalpursuit.com> wrote:
> Jochen -
> Excellent news! Great work and please pass my congratulations along to
> the entire Wave team.
> I'll also offer my opinion that I believe that having that test suite
> soon is of critical importance to making sure that, as you say, all
> Wave server providers are providing the same and latest up-to-date
> protocol support.
> Because Google (very, very smartly, IMHO) chose to use XMPP (and I
> noticed in the latest Wave protocol version to use XEP-60 PubSub -
> very good choice), that there are a load of XMPP server vendors out
> there. All of the major players are using XMPP servers for their
> collaboration products: Sun, Oracle, HP, IBM - both Lotus and non-
> Lotus, Cisco (Jabber Inc.), etc. etc and the list goes on and on.
> Therefore, it will be easy for these folks to add Wave protocol
> support to their products. This makes Wave Protocol adoption almost
> frictionless.
> Of course, those of us 'in the market' for a Wave Server to install
> inside & outside of our corporate firewalls will want to make sure
> that the Wave Server we're buying (or the XMPP server we've already
> bought that is getting a "Wave upgrade") is fully 'protocol compliant'
> and that it properly implements the CC functionality as per Google's
> specification. The only way we'll know that is if the product is
> passing that test suite. You may even want to come up with a 'Wave
> Inside' branding effort for XMPP servers that pass the full Wave test
> suite (but I'll leave that to your marketing folks :-) ).
> Therefore, I'm giving a big '+1' to the test suite :-)
> Cheers,
> - Bill
> On Jul 24, 5:15 pm, Jochen Bekmann <joc...@google.com> wrote:
>> .....
>> We will be releasing a test
>> and verification suite for those who'd like to do their own
>> implementation (e.g. for porting the code to other languages), but we
>> cannot put a date on that yet.
>> .....
>> Jochen Bekmann
>> Software Engineer, Google Wave
Is there any plans to incorporate a OT version into part of the federation handshaking or
requirements discovery by servers? My assumption here is that 0.1 (currently in production) will
not inter-operate with 0.2.
Jochen Bekmann wrote:
> We have released the first, small part of the Google Wave codebase
> together with a prototype implementation of a federated wave server
> and lightweight text client under the Apache 2.0 license. Please see
> the Wave Protocol project on Google Code
> (http://code.google.com/p/wave-protocol).
> The release includes the wave data model, including the operations and
> the operational transformation algorithm. The released version is a
> close copy of our production code, and is in fact an iteration beyond
> what is currently running on WaveSandbox (we are working to catch up).
> Please note that all the code is still under active development and we
> do expect to make modifications to it, especially in the short term.
> We have updated the documentation to reflect these new operations. As
> you probably know, the Operational Transformation (OT) code is the
> heart and soul of Google Wave's collaboration - it makes it possible
> for users to have the highly collaborative experience of wave. OT is
> part of a concurrency control (CC) algorithm that is responsible for
> ensuring wave clients can optimistically modify documents locally yet
> keep in sync with the canonical state of a wave on a server and that
> all clients will converge on the canonical state of a wave eventually
> (when everyone stops typing). In a federated system, it is critical
> that each wave provider manage the operation stream consistently,
> otherwise convergence cannot be guaranteed. This means it is highly
> recommended that anyone attempting to federate waves should exactly
> match the CC functionality of every other wave server. We believe this
> is easiest if our released code is used. We will be releasing a test
> and verification suite for those who'd like to do their own
> implementation (e.g. for porting the code to other languages), but we
> cannot put a date on that yet. The OT code as is now released is not
> quite complete and we hope to add the missing bits soon. However, as
> it stands it will do a lot of the concurrent editing that is inherent
> to wave.
> The wave model code is a simplified version of our production code and
> is tied to the OT code. This code will evolve into the shared codebase
> (that we'll use and we hope others will too).
> Source code under "FedOne" is the prototype wave server with
> federation support and a "toy" text client. The wave server is not a
> production-quality implementation (for example it currently keeps all
> wavelets' state in memory only!), but may serve as a foundation for
> one. At this time its main function is to provide an executable spec
> for how to "speak" wave federation, and as a good starting point for
> people to develop their own servers. We intend to expand the code
> base, but at this point are not sure of exactly how far. (And a 'heads
> up': a few features necessary for correct security support need to be
> fixed in the next few days).
> The architecture of the wave server, federation host, and federation
> remote closely mimic the way our production servers work. Please see
> the online documentation for a description of the wave architecture.
> (http://www.waveprotocol.org).
> The text client was included to show how a client may interact with
> the server. The client/server protocol is very simple and for
> illustrative purposes only. The client as implemented does not do full
> OT - it sends simple updates containing a line of entered text to the
> server to apply as a paragraph. There is no reason why the client
> could not be extended to use the full OT code, we merely chose to
> implement something slightly easier, and also show how one might "talk
> wave" without having OT in the client. You will note the interesting
> design of the client's inbox - it's sent as a live updating wave. This
> is an experiment in the "everything's a wave" paradigm. The
> client/server protocol is not intended as a standard at this point. In
> the future, we hope to figure out (with help from the community) how
> we may get to some standardization.
> We have started up federated wave servers on acmewave.com and
> initech-corp.com. You can go ahead and connect to them. Note, however,
> that we don't have any users on those servers, so there won't be
> anyone to chat to right now. (We might add a robot that chats with
> remote participants, or maybe someone in this forum could write one
> and tell us about it... :) You can, of course, bring up your own
> instances and exchange details here on the forum, allowing you to
> federate.
> Next, we will work to get our own system using the new OT and get
> federation supported for wavesandbox.com (and then wave.google.com),
> hopefully we'll do so by the September 30th extended preview, but note
> that it's a stretch goal.
> We hope to see some really cool implementations based on the released
> code and we're looking forward to federating your waves come September
> 30th.
This is great. I have it running locally. The federation seems to
have a problem though (perhaps just my misunderstanding).
When I add "remote" user I see the request in the server log to do the
Items Get:
<iq type="get" id="7998-1" to="acmewave.com"
from="wave.dev.myserver.com">
<query xmlns="http://jabber.org/protocol/disco#items"/>
</iq>
> This is great. I have it running locally. The federation seems to
> have a problem though (perhaps just my misunderstanding).
> When I add "remote" user I see the request in the server log to do the
> Items Get:
> <iq type="get" id="7998-1" to="acmewave.com"
> from="wave.dev.myserver.com">
> <query xmlns="http://jabber.org/protocol/disco#items"/>
> </iq>
Great to see you're talking to our servers! We're considering
arranging "office hours", where Googlers are available to talk both
via the open-source implementation of Wave, and via a wave on Wave
Sandbox. Watch this space for potential times.
Having said that, if anyone (including you, WaveyGravey) would like to
add thorog...@acmewave.com to your waves in order to have some
back-and-worth waving, I'm going to leave a client open between around
10.00 - 18.00, AEST, which equates to 17.00 - 1.00 PST.
On Wed, Jul 29, 2009 at 01:03, WaveyGravey<homer...@gmail.com> wrote:
> Ah, I got it. I needed to "open" up port 5269 on my server. Seems to
> be working now :-)
> On Jul 28, 10:41 am, WaveyGravey <homer...@gmail.com> wrote:
>> This is great. I have it running locally. The federation seems to
>> have a problem though (perhaps just my misunderstanding).
>> When I add "remote" user I see the request in the server log to do the
>> Items Get:
>> <iq type="get" id="7998-1" to="acmewave.com"
>> from="wave.dev.myserver.com">
>> <query xmlns="http://jabber.org/protocol/disco#items"/>
>> </iq>
> Great to see you're talking to our servers! We're considering > arranging "office hours", where Googlers are available to talk both > via the open-source implementation of Wave, and via a wave on Wave > Sandbox. Watch this space for potential times.
> Having said that, if anyone (including you, WaveyGravey) would like to > add thorog...@acmewave.com to your waves in order to have some > back-and-worth waving, I'm going to leave a client open between around > 10.00 - 18.00, AEST, which equates to 17.00 - 1.00 PST.
I've added you to my server (wave.collaborynth.com.au) here's hoping it all works :)
I can see a few incoming deltas on the acmewave.com logs - including
the add participant - can you send me a couple more messages? There is
currently an issue where a Wave won't show up in your digest until
after a couple of deltas (to do with having to turn around and request
history) have been received.
On Wed, Jul 29, 2009 at 09:54, James Purser<jamesrpur...@gmail.com> wrote:
> Sam Thorogood wrote:
>> Hi,
>> Great to see you're talking to our servers! We're considering
>> arranging "office hours", where Googlers are available to talk both
>> via the open-source implementation of Wave, and via a wave on Wave
>> Sandbox. Watch this space for potential times.
>> Having said that, if anyone (including you, WaveyGravey) would like to
>> add thorog...@acmewave.com to your waves in order to have some
>> back-and-worth waving, I'm going to leave a client open between around
>> 10.00 - 18.00, AEST, which equates to 17.00 - 1.00 PST.
> I've added you to my server (wave.collaborynth.com.au) here's hoping it
> all works :)
Sam Thorogood wrote: > I can see a few incoming deltas on the acmewave.com logs - including > the add participant - can you send me a couple more messages? There is > currently an issue where a Wave won't show up in your digest until > after a couple of deltas (to do with having to turn around and request > history) have been received.
> I can see a few incoming deltas on the acmewave.com logs - including
> the add participant - can you send me a couple more messages? There is
> currently an issue where a Wave won't show up in your digest until
> after a couple of deltas (to do with having to turn around and request
> history) have been received.
> On Wed, Jul 29, 2009 at 09:54, James Purser<jamesrpur...@gmail.com> wrote:
> > Sam Thorogood wrote:
> >> Hi,
> >> Great to see you're talking to our servers! We're considering
> >> arranging "office hours", where Googlers are available to talk both
> >> via the open-source implementation of Wave, and via a wave on Wave
> >> Sandbox. Watch this space for potential times.
> >> Having said that, if anyone (including you, WaveyGravey) would like to
> >> add thorog...@acmewave.com to your waves in order to have some
> >> back-and-worth waving, I'm going to leave a client open between around
> >> 10.00 - 18.00, AEST, which equates to 17.00 - 1.00 PST.
> > I've added you to my server (wave.collaborynth.com.au) here's hoping it
> > all works :)
Have been trying to test with James.
We're having a little trouble with the pubsub and conference services
interfering. Seems that maybe acmewave doesn't have problems because for
some reason it lists wave first
On Tue, Jul 28, 2009 at 7:29 PM, Mark Achée <mac...@gmail.com> wrote:
> I added you to a wave a sent a few deltas also, from achee.com
> On Tue, Jul 28, 2009 at 7:09 PM, Sam Thorogood <sam.thorog...@gmail.com>wrote:
>> I can see a few incoming deltas on the acmewave.com logs - including
>> the add participant - can you send me a couple more messages? There is
>> currently an issue where a Wave won't show up in your digest until
>> after a couple of deltas (to do with having to turn around and request
>> history) have been received.
>> On Wed, Jul 29, 2009 at 09:54, James Purser<jamesrpur...@gmail.com>
>> wrote:
>> > Sam Thorogood wrote:
>> >> Hi,
>> >> Great to see you're talking to our servers! We're considering
>> >> arranging "office hours", where Googlers are available to talk both
>> >> via the open-source implementation of Wave, and via a wave on Wave
>> >> Sandbox. Watch this space for potential times.
>> >> Having said that, if anyone (including you, WaveyGravey) would like to
>> >> add thorog...@acmewave.com to your waves in order to have some
>> >> back-and-worth waving, I'm going to leave a client open between around
>> >> 10.00 - 18.00, AEST, which equates to 17.00 - 1.00 PST.
>> > I've added you to my server (wave.collaborynth.com.au) here's hoping it
>> > all works :)
Mark Achée wrote: > Have been trying to test with James.
> We're having a little trouble with the pubsub and conference services > interfering. Seems that maybe acmewave doesn't have problems because > for some reason it lists wave first
> I assume adding pubsub to my dns will fix this (noticed > pubsub.acmewave.com <http://pubsub.acmewave.com> resolves) but I > expect it's not the ideal solution.
Okay just to follow up I have done the following on my openfire server:
Disabled Group Chat by doing the following:
- Logged Into OpenFire Admin Panel - Clicked on Group Chat - Clicked on Group Chat Settings - Delete the conferences domain
Disabled Pubsub by doing the following:
- Clicked on Server - Clicked on System Properties - Added the following Property: xmpp.pubsub.enabled and set it to false.
I then restarted everything and Mark ran a ping test which returned the expected
Okay, we managed to get the ping to work and went onto trying to hold a conversation.
Mark started off and the new wave appeared on the left for me, however when I replied, his client wasn't updating. On further investigation his server reported the following:
and signature: signatureBytes: "\025\016\251\224\3566\371&f{\206Jx\242,/\253\374\311R\354I\236\201\r\246\3 35\324:\nN\034\212\274J\354ZTU4\3031%\326 =\216=\305\313\254\203\271\231\240a\2617f7\363\270\253\356\334G-PY\034\353\ 331\235:\0234\341\206$\223L&\330[|\307S\347\035\342\225M\001\003\266\313\27 2\026\360\205\f>\311\255\320\231|\022\331\217\365\362\035N\003\376\323/\273 \325\263)\253\325\347\363\2361"
at org.waveprotocol.wave.examples.fedone.waveserver.CertificateManagerImpl.ver ifySingleSignature(CertificateManagerImpl.java:143) at org.waveprotocol.wave.examples.fedone.waveserver.CertificateManagerImpl.ver ifyDelta(CertificateManagerImpl.java:122) at org.waveprotocol.wave.examples.fedone.waveserver.WaveServerImpl.submitReque st(WaveServerImpl.java:191) at org.waveprotocol.wave.examples.fedone.federation.xmpp.XmppFederationHost.pr ocessSubmitRequest(XmppFederationHost.java:193) at org.waveprotocol.wave.examples.fedone.federation.xmpp.WaveXmppComponent.pro cessPubsubSet(WaveXmppComponent.java:450) at org.waveprotocol.wave.examples.fedone.federation.xmpp.WaveXmppComponent.pro cessIqPacket(WaveXmppComponent.java:404) at org.waveprotocol.wave.examples.fedone.federation.xmpp.WaveXmppComponent.pro cessPacket(WaveXmppComponent.java:338) at org.jivesoftware.whack.ExternalComponent$1.run(ExternalComponent.java:333) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.j ava:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java: 908) at java.lang.Thread.run(Thread.java:619) Caused by: org.waveprotocol.wave.examples.fedone.crypto.UnknownSignerException: could not find information about signer com.google.protobuf.ByteString@ed124599 at org.waveprotocol.wave.examples.fedone.crypto.WaveSignatureVerifier.verify(W aveSignatureVerifier.java:83) at org.waveprotocol.wave.examples.fedone.waveserver.CertificateManagerImpl.ver ifySingleSignature(CertificateManagerImpl.java:141) ... 10 more
I presume you started the server using the run-server.sh script ? Due
to an outstanding issue, the signature verification code is not quite
working yet. I have updated the run-server.sh script to temporarily
disable verification, please check whether your problem is solved by
this (ref http://wave-codereview.appspot.com/1007).
On Tue, Jul 28, 2009 at 8:49 PM, James Purser<jamesrpur...@gmail.com> wrote:
> Okay, we managed to get the ping to work and went onto trying to hold a
> conversation.
> Mark started off and the new wave appeared on the left for me, however
> when I replied, his client wasn't updating. On further investigation his
> server reported the following:
> at
> org.waveprotocol.wave.examples.fedone.waveserver.CertificateManagerImpl.ver ifySingleSignature(CertificateManagerImpl.java:143)
> at
> org.waveprotocol.wave.examples.fedone.waveserver.CertificateManagerImpl.ver ifyDelta(CertificateManagerImpl.java:122)
> at
> org.waveprotocol.wave.examples.fedone.waveserver.WaveServerImpl.submitReque st(WaveServerImpl.java:191)
> at
> org.waveprotocol.wave.examples.fedone.federation.xmpp.XmppFederationHost.pr ocessSubmitRequest(XmppFederationHost.java:193)
> at
> org.waveprotocol.wave.examples.fedone.federation.xmpp.WaveXmppComponent.pro cessPubsubSet(WaveXmppComponent.java:450)
> at
> org.waveprotocol.wave.examples.fedone.federation.xmpp.WaveXmppComponent.pro cessIqPacket(WaveXmppComponent.java:404)
> at
> org.waveprotocol.wave.examples.fedone.federation.xmpp.WaveXmppComponent.pro cessPacket(WaveXmppComponent.java:338)
> at
> org.jivesoftware.whack.ExternalComponent$1.run(ExternalComponent.java:333)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.j ava:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java: 908)
> at java.lang.Thread.run(Thread.java:619)
> Caused by:
> org.waveprotocol.wave.examples.fedone.crypto.UnknownSignerException:
> could not find information about signer
> com.google.protobuf.ByteString@ed124599
> at
> org.waveprotocol.wave.examples.fedone.crypto.WaveSignatureVerifier.verify(W aveSignatureVerifier.java:83)
> at
> org.waveprotocol.wave.examples.fedone.waveserver.CertificateManagerImpl.ver ifySingleSignature(CertificateManagerImpl.java:141)
> ... 10 more
> I presume you started the server using the run-server.sh script ? Due > to an outstanding issue, the signature verification code is not quite > working yet. I have updated the run-server.sh script to temporarily > disable verification, please check whether your problem is solved by > this (ref http://wave-codereview.appspot.com/1007).
> thanks, > Jochen
Hi Jochen,
Yar I switched off verification, the reported stack dump came from Marks side of the conversation but he's gone to bed :)
Since then I've managed to have a federated conversation with Sam Thorogood, so we're good to go (will make changes to the How To I wrote to reflect the openfire information).
On Tue, Jul 28, 2009 at 10:37 PM, James Purser<jamesrpur...@gmail.com> wrote:
> Jochen Bekmann wrote: >> James,
>> I presume you started the server using the run-server.sh script ? Due >> to an outstanding issue, the signature verification code is not quite >> working yet. I have updated the run-server.sh script to temporarily >> disable verification, please check whether your problem is solved by >> this (ref http://wave-codereview.appspot.com/1007).
>> thanks, >> Jochen
> Hi Jochen,
> Yar I switched off verification, the reported stack dump came from Marks > side of the conversation but he's gone to bed :)
> Since then I've managed to have a federated conversation with Sam > Thorogood, so we're good to go (will make changes to the How To I wrote > to reflect the openfire information).
On Wed, Jul 29, 2009 at 12:19 AM, Jochen Bekmann <joc...@google.com> wrote:
> James,
> I presume you started the server using the run-server.sh script ? Due
> to an outstanding issue, the signature verification code is not quite
> working yet. I have updated the run-server.sh script to temporarily
> disable verification, please check whether your problem is solved by
> this (ref http://wave-codereview.appspot.com/1007).
> thanks,
> Jochen
> On Tue, Jul 28, 2009 at 8:49 PM, James Purser<jamesrpur...@gmail.com>
> wrote:
> > Okay, we managed to get the ping to work and went onto trying to hold a
> > conversation.
> > Mark started off and the new wave appeared on the left for me, however
> > when I replied, his client wasn't updating. On further investigation his
> > server reported the following:
> org.waveprotocol.wave.examples.fedone.waveserver.CertificateManagerImpl.ver ifySingleSignature(CertificateManagerImpl.java:143)
> > at
> org.waveprotocol.wave.examples.fedone.waveserver.CertificateManagerImpl.ver ifyDelta(CertificateManagerImpl.java:122)
> > at
> org.waveprotocol.wave.examples.fedone.waveserver.WaveServerImpl.submitReque st(WaveServerImpl.java:191)
> > at
> org.waveprotocol.wave.examples.fedone.federation.xmpp.XmppFederationHost.pr ocessSubmitRequest(XmppFederationHost.java:193)
> > at
> org.waveprotocol.wave.examples.fedone.federation.xmpp.WaveXmppComponent.pro cessPubsubSet(WaveXmppComponent.java:450)
> > at
> org.waveprotocol.wave.examples.fedone.federation.xmpp.WaveXmppComponent.pro cessIqPacket(WaveXmppComponent.java:404)
> > at
> org.waveprotocol.wave.examples.fedone.federation.xmpp.WaveXmppComponent.pro cessPacket(WaveXmppComponent.java:338)
> > at
> org.jivesoftware.whack.ExternalComponent$1.run(ExternalComponent.java:333)
> > at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.j ava:886)
> > at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java: 908)
> > at java.lang.Thread.run(Thread.java:619)
> > Caused by:
> > org.waveprotocol.wave.examples.fedone.crypto.UnknownSignerException:
> > could not find information about signer
> > com.google.protobuf.ByteString@ed124599
> > at
> org.waveprotocol.wave.examples.fedone.crypto.WaveSignatureVerifier.verify(W aveSignatureVerifier.java:83)
> > at
> org.waveprotocol.wave.examples.fedone.waveserver.CertificateManagerImpl.ver ifySingleSignature(CertificateManagerImpl.java:141)
> > ... 10 more
We appreciate the need for such a test suite and an endorsement
process. As I wrote in the announcement, unfortunately we won't find
time soon to release one. In the short term, interoperability could be
defined as being able to interact with the code we have released, and
once we open a federation port on our production systems, interact
with that. This is of course not exactly ideal as this kind of testing
is likely to only show up superficial problems.
The protocol is a fairly comprehensive one, and protocol conformance
could be tested in two main areas: 1) being able to exchange valid
XMPP messages according to the wire specification as described in the
protocol spec (http://www.waveprotocol.org/draft-protocol-spec), and
2) making sure that an implementation generates valid operations
relative to the state of a wave, correctly applies operations to a
wave (resulting in exactly the same state as other wave participants)
and correctly transforms operations (matching the transformations made
by other wave participants). This latter requirement (2) is part of
the Google Wave Federation Protocol, but so far has not been
explicitly described and instead we've provided an executable spec
with the code released to http://code.google.com/p/wave-protocol/.
Both 1) and 2) can be tested at the XMPP level, with 2) being the more
onerous task: in order to reach some level of assurance on
correctness, a large state space needs to be explored to validate the
communicating entities. Problems may arise only after a non-trivial
divergence of participants' wave state, requiring a long sequence of
operations that need to be exchanged, transformed and applied.We are
close to releasing thorough unit tests for our OT code. This code will
not have an XMPP front-end, but hopefully we will find time to add
this too, alternatively someone in the community may help with that ?
It would be cool for developers in the wave protocol community to be
able to test and endorse each other's implementations. Out of this
effort, a compliance process could evolve.
regards,
Jochen Bekmann
Software Engineer, Google Wave
On Fri, Jul 24, 2009 at 6:15 PM, bedney<bed...@technicalpursuit.com> wrote:
> Jochen -
> Excellent news! Great work and please pass my congratulations along to
> the entire Wave team.
> I'll also offer my opinion that I believe that having that test suite
> soon is of critical importance to making sure that, as you say, all
> Wave server providers are providing the same and latest up-to-date
> protocol support.
> Because Google (very, very smartly, IMHO) chose to use XMPP (and I
> noticed in the latest Wave protocol version to use XEP-60 PubSub -
> very good choice), that there are a load of XMPP server vendors out
> there. All of the major players are using XMPP servers for their
> collaboration products: Sun, Oracle, HP, IBM - both Lotus and non-
> Lotus, Cisco (Jabber Inc.), etc. etc and the list goes on and on.
> Therefore, it will be easy for these folks to add Wave protocol
> support to their products. This makes Wave Protocol adoption almost
> frictionless.
> Of course, those of us 'in the market' for a Wave Server to install
> inside & outside of our corporate firewalls will want to make sure
> that the Wave Server we're buying (or the XMPP server we've already
> bought that is getting a "Wave upgrade") is fully 'protocol compliant'
> and that it properly implements the CC functionality as per Google's
> specification. The only way we'll know that is if the product is
> passing that test suite. You may even want to come up with a 'Wave
> Inside' branding effort for XMPP servers that pass the full Wave test
> suite (but I'll leave that to your marketing folks :-) ).
> Therefore, I'm giving a big '+1' to the test suite :-)
> Cheers,
> - Bill
> On Jul 24, 5:15 pm, Jochen Bekmann <joc...@google.com> wrote:
>> .....
>> We will be releasing a test
>> and verification suite for those who'd like to do their own
>> implementation (e.g. for porting the code to other languages), but we
>> cannot put a date on that yet.
>> .....
>> Jochen Bekmann
>> Software Engineer, Google Wave
As Anthony stated above, your current server is XEP-114 compliant,
which means that it can be used with a variety of Jabber servers, and
that is great!
My concern is that I know of at least 2 non-Java server
implementations that are currently being developed (Python PyGoWave
and Erlang ejabberd, specifically) and I'm about ready to start
another one.
As you state above, #1 should be pretty easy to test - its #2 that I'm
worried about. Glad to hear the OT test code itself is not far away
from release. Getting an XMPP front-end on it is obviously necessary
to test non-Java servers. Other vendors who have XMPP server codebases
written in Java should have an easier time of it.
My biggest concern here is vendors rushing off to 'upgrade their XMPP
servers to add Google Wave technology!' :-), but then not having it
pass a compliance suite and having a bunch of 'corrupt' Waves being
vended around out there. We've all seen issues like this in the past
with protocols in the past (vendors jumping the gun on
implementation), but this is different in that serialized Wave data
that will live forever is involved (so its worse, actually).
Just my 2 cents here :-).
Thanks for the communication effort - it is appreciated.
Cheers,
- Bill
On Jul 31, 10:18 pm, Jochen Bekmann <joc...@google.com> wrote:
> We appreciate the need for such a test suite and an endorsement
> process. As I wrote in the announcement, unfortunately we won't find
> time soon to release one. In the short term, interoperability could be
> defined as being able to interact with the code we have released, and
> once we open a federation port on our production systems, interact
> with that. This is of course not exactly ideal as this kind of testing
> is likely to only show up superficial problems.
> The protocol is a fairly comprehensive one, and protocol conformance
> could be tested in two main areas: 1) being able to exchange valid
> XMPP messages according to the wire specification as described in the
> protocol spec (http://www.waveprotocol.org/draft-protocol-spec), and
> 2) making sure that an implementation generates valid operations
> relative to the state of a wave, correctly applies operations to a
> wave (resulting in exactly the same state as other wave participants)
> and correctly transforms operations (matching the transformations made
> by other wave participants). This latter requirement (2) is part of
> the Google Wave Federation Protocol, but so far has not been
> explicitly described and instead we've provided an executable spec
> with the code released tohttp://code.google.com/p/wave-protocol/.
> Both 1) and 2) can be tested at the XMPP level, with 2) being the more
> onerous task: in order to reach some level of assurance on
> correctness, a large state space needs to be explored to validate the
> communicating entities. Problems may arise only after a non-trivial
> divergence of participants' wave state, requiring a long sequence of
> operations that need to be exchanged, transformed and applied.We are
> close to releasing thorough unit tests for our OT code. This code will
> not have an XMPP front-end, but hopefully we will find time to add
> this too, alternatively someone in the community may help with that ?
> It would be cool for developers in the wave protocol community to be
> able to test and endorse each other's implementations. Out of this
> effort, a compliance process could evolve.
> regards,
> Jochen Bekmann
> Software Engineer, Google Wave
> On Fri, Jul 24, 2009 at 6:15 PM, bedney<bed...@technicalpursuit.com> wrote:
> > Jochen -
> > Excellent news! Great work and please pass my congratulations along to
> > the entire Wave team.
> > I'll also offer my opinion that I believe that having that test suite
> > soon is of critical importance to making sure that, as you say, all
> > Wave server providers are providing the same and latest up-to-date
> > protocol support.
> > Because Google (very, very smartly, IMHO) chose to use XMPP (and I
> > noticed in the latest Wave protocol version to use XEP-60 PubSub -
> > very good choice), that there are a load of XMPP server vendors out
> > there. All of the major players are using XMPP servers for their
> > collaboration products: Sun, Oracle, HP, IBM - both Lotus and non-
> > Lotus, Cisco (Jabber Inc.), etc. etc and the list goes on and on.
> > Therefore, it will be easy for these folks to add Wave protocol
> > support to their products. This makes Wave Protocol adoption almost
> > frictionless.
> > Of course, those of us 'in the market' for a Wave Server to install
> > inside & outside of our corporate firewalls will want to make sure
> > that the Wave Server we're buying (or the XMPP server we've already
> > bought that is getting a "Wave upgrade") is fully 'protocol compliant'
> > and that it properly implements the CC functionality as per Google's
> > specification. The only way we'll know that is if the product is
> > passing that test suite. You may even want to come up with a 'Wave
> > Inside' branding effort for XMPP servers that pass the full Wave test
> > suite (but I'll leave that to your marketing folks :-) ).
> > Therefore, I'm giving a big '+1' to the test suite :-)
> > Cheers,
> > - Bill
> > On Jul 24, 5:15 pm, Jochen Bekmann <joc...@google.com> wrote:
> >> .....
> >> We will be releasing a test
> >> and verification suite for those who'd like to do their own
> >> implementation (e.g. for porting the code to other languages), but we
> >> cannot put a date on that yet.
> >> .....
> >> Jochen Bekmann
> >> Software Engineer, Google Wave
INFO: Starting client frontend on host 127.0.0.1 port: 9876
couldn't connect to XMPP server:org.xmpp.component.ComponentException:
host-unknown
Although I always get this message, sometimes the server does actually
start and I can connect to it with the client, most of the time not.
Any help on what I am missing?
On Wed, Aug 5, 2009 at 05:29, AlDanks<altonda...@gmail.com> wrote:
> When I attempt to start my wave server I see:
> INFO: Starting client frontend on host 127.0.0.1 port: 9876
> couldn't connect to XMPP server:org.xmpp.component.ComponentException:
> host-unknown
> Although I always get this message, sometimes the server does actually
> start and I can connect to it with the client, most of the time not.
> Any help on what I am missing?
AlDanks, you need to change the option "--xmpp_component_name=NAME" in
the command of java run.
NAME must be identical to the name that you entered as the name of the
external component (subdomain) in Openfire or in another jabber-
server.
On 5 авг, 01:29, AlDanks <altonda...@gmail.com> wrote:
> INFO: Starting client frontend on host 127.0.0.1 port: 9876
> couldn't connect to XMPP server:org.xmpp.component.ComponentException:
> host-unknown
> Although I always get this message, sometimes the server does actually
> start and I can connect to it with the client, most of the time not.
> Any help on what I am missing?
jsexton@iws03svn1:~/work/wave-protocol$ ./run-server.sh
Aug 20, 2009 11:31:57 AM
org.waveprotocol.wave.examples.fedone.waveserver.CertificateManagerImpl
<init>
WARNING: ** SIGNATURE VERIFICATION DISABLED ** see flag
"waveserver_disable_verification"
Aug 20, 2009 11:31:57 AM
org.waveprotocol.wave.examples.fedone.waveserver.WaveServerImpl <init>
INFO: Wave Server configured to host local domains: [localhost]
Aug 20, 2009 11:31:57 AM
org.waveprotocol.wave.examples.fedone.ServerMain
$RpcInetSocketAddressFactory <init>
INFO: Starting client frontend on host: 127.0.0.1 port: 9876
couldn't connect to XMPP server:org.xmpp.component.ComponentException:
host-unknown
Aug 20, 2009 11:31:58 AM
org.waveprotocol.wave.examples.fedone.ServerMain run
INFO: Starting server
This then hangs.
The Openfire server is running, it's port is 5269
On Aug 6, 3:08 am, vadbars <vadb...@gmail.com> wrote:
> AlDanks, you need to change the option "--xmpp_component_name=NAME" in
> the command of java run.
> NAME must be identical to the name that you entered as the name of the
> external component (subdomain) in Openfire or in another jabber-
> server.
> On 5 авг, 01:29, AlDanks <altonda...@gmail.com> wrote:
> > Although I always get this message, sometimes the server does actually
> > start and I can connect to it with the client, most of the time not.
> > Any help on what I am missing?
> AlDanks, you need to change the option "--xmpp_component_name=NAME" in
> the command of java run.
> NAME must be identical to the name that you entered as the name of the
> external component (subdomain) in Openfire or in another jabber-
> server.
> On 5 авг, 01:29, AlDanks <altonda...@gmail.com> wrote:
> > Although I always get this message, sometimes the server does actually
> > start and I can connect to it with the client, most of the time not.
> > Any help on what I am missing?
