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.
No comments:
Post a Comment