WaveOne Wave Server Implementation
This post is part of the Who's
@ Google I/O, a series of blog posts that give a closer look at developers who'll be
speaking or demoing at Google
I/O. This guest post is written by Mickaël Rémond, Founder of ProcessOne, who will
be demoing as part of the Developer
Sandbox.When the Google Wave protocol and platform
was
announced
at Google I/O in 2009, ProcessOne became an immediate fan.
What we like most is the real time nature of the protocol, which is currently critical in
any new web service. We also like the fact that it integrates well in an asynchronous
workflow, allowing developers to work together at the same time on the same content, even the
same character. (This is, however, an extra feature and you don’t have to use it.)
In addition, we are keen on the ability to integrate gadgets, acting as mini
applications, inside each conversation. This opens up a new level of opportunity to integrate
various applications together in the same place. It can be seen as ‘cloud glue’, a simple way
to aggregate rich data available from different applications and different application
providers.
However, the most powerful enabler is the
Google Wave Federation Protocol, which allows
developers to have several domains, and thus build several different content management
platforms, with the ability to act as a single interoperable tool. It does not matter if you
do not want to host your company data on Google Wave server; you can instead deploy your own
Wave compliant tool internally and still collaborate with people outside your organisation on
that content. This is cross-organization document workflow.
Since the
announcement of Wave, ProcessOne has been excited by the possibilities offered by this new
protocol. Federation was build on top of XMPP (eXtensible Messaging and Presence Protocol), a
domain in which ProcessOne is already a leading provider. It was a natural progression for us
to extend our platform to support Wave.
We decided to develop such an
extension for our XMPP server, but we took the hard way. We developed our own completely new
Wave server, to prove that this protocol was really interoperable with implementations from
different code bases. We also wanted to prove that the new platform would meet our high
expectations for integration, performance and scalability. Of course, we read the FedOne code
source to understand specific aspects of the underlying Wave protocol, but we did an
implementation from scratch (in Erlang).
So, how far has ProcessOne
gotten?
We are proud to have a full Wave server implementation, both
with an operational transform engine and a Wave store. We have designed a client protocol that
works on XMPP, meaning that we can directly get the wave information in our OneTeam chat and
VoIP client. We have even implemented this protocol in two XMPP clients (Tkabber and OneTeam)
to validate the concept.
We have now reached a point where federation
works, both with FedOne and Google Wave Developer Sandbox. This means that you can host waves
on our server and invite people to join from any other known Wave service, or do the reverse
and participate in a Wave document that is managed by another service.
What are the next steps?
From here, we need to take a few more
steps to fully unleash the full potential of Wave (like
OpenSocial support), but we have the foundation for
an innovative collaboration platform. This Wave service will be deployed as an experimental
option on our hosted messaging offering (Hosted.IM) in June. We therefore expect to become the
first independent Wave Service Provider.
We also hope that our
implementation will be the first seed, from which many other large Wave services will grow and
spread around the world.
Let's meet in Google I/O
Developer Sandbox to
talk about the future of the Wave platform. We look forward to seeing you there.
Posted by
Mickaël Rémond, Founder of ProcessOne
