ProcessOne Wave Server: ejabberd extension video

It looks greate. Good work guys. Show some distributed features, start 3 ejabbers serving independend domain. Why you are using Google’s protocol for client 2 server communication? How about using just some simple XML protocol? I think Google is using protobuffers only because of performance. I know that performance is important, but protobuffers doesn’t fit nicely into XMPP , and there are no such much support of parsing them in many languages.

Have you implemented protobuffers into erlang? I was going to write it, but it looks that you already done this?

We are using XMPP for client to server protocol (as you see we are using an XMPP client).
And yes, one of the things you need to support is protocol buffer from Google.

If you made edits to the Wave simultaneously (e.g., type on two computers running TKabber) is the result corrected for consistency? I’m wonder, where does the operational transformation algorithm live in Wave. Is that something you have implemented or need to implement?

We have implemented the transformation algorithm proposed by Google in the Wave protocol, which includes the needed rules to merge simultaneous changes.

When we can (and can we) wait for ejabberd extension sourcecode?

We do not know yet what will be done with the Wave server.

Hi Mickaël,

Most impressive demo. Nice to see a Wave client with the realtime communication.

/daniel

Interesting! The Wave landscape is hotting up!

Witold, there is an implementation of Protocol Buffers in Erlang: http://github.com/ngerakines/erlang_protobuffs/tree/master that I used for my Wave client: http://21ccw.blogspot.com/2009/08/my-google-wave-client.html. It does require a bit of modification of the .proto files.

Mickaël -

Very impressive work!

I’m curious. There are two ways to implement the OT algorithms:

#1: both on the client and in the server.
#2: on the server only, with the client acting very ‘dumb’ and just sending characters. This is the way the FedOne server operates.

Which did you choose here? I assume that if it was #1 that you also had to implement OT algorithms in TCL in the client?

Cheers,

- Bill

P.S. Very, very interested in a public release of the ejabberd Wave server :-). If you’re interested, I did a presentation on Wave for the “St. Louis, Missouri Wave Hackfest”. That can be seen here: http://blip.tv/file/2519604

Hi Mickaël,

Well done, the Google Wave team is excited to see your progress on both an alternative implementation of a wave server and a client. It would be very cool to see some interop with FedOne at some point :)

As for using protobufs - they are needed mostly as a canonical format to be cryptographically signed and shared between servers (for further discussion on this choice please see http://groups.google.com/group/wave-protocol). If the demo’d clients speak a dialect of the FedOne client/server protocol, they does not necessarily have to use protobufs.

Happy waving,
Jochen

The conflicts resolution is fully handled by the server and by the client with slightly different rules. They must end up with the same state if rules are correct.

Impressive demo for a google wave extension. Quite detailed enough to introduce such new application. Good job and thanks for sharing.