MatrixAdapt | Logiciel de gestion d'Entreprise, Création et référencement des sites web

Seo Master present to you: 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 ProcessOne2013, By: Seo Master

Seo Master present to you: You have seen the previews for I/O sessions that we have published so far (First set, Second set). This time, we have something a little different for you.

In this preview, Brian and Ben track down the elusive Genius programmer in the preview for their session, "The Myth of the Genius Programmer". Will they succeed in their quest? Will they live to tell the tale? Watch the preview to find out.

The Myth of the Genius Programmer - Brian Fitzpatrick & Ben Collins-Sussman



Keep an eye out for more previews on the other sessions at I/O in the coming soon. We can't wait to meet a bunch of talented developers and have some fun at Google I/O, on May 27-28!

By Neel Kshetramade, Google Developer Programs2013, By: Seo Master

Seo Master present to you: With Google I/O 2010 finally upon us, what better time to introduce developers to the latest updates to the Google Buzz API?

As announced at the launch of Google Buzz, the Google Buzz API aligns itself with the ever-growing family of freely available and community-developed protocols, formats, and standards for sharing and consuming social content on the web, including ActivityStreams, Atom, AtomPub, JSON, OAuth, PubSubHubbub, MediaRSS, PortableContacts, and more.

The Google Buzz API, a member of the Google Code Labs, is very much a work in progress — we intend to continue to iterate out in the open as we go along — and we hope the features we are making available today will help inspire developers and provide a solid foundation for new applications to be built.

We are already excited to see developers who were helping us test the API deliver terrific applications. Today you'll start seeing the following sites and services integrate with Google Buzz:


End-users opt into using applications built with the Google Buzz API via an interstitial confirmation screen outlining the application's requested access scope (read-only, read/write, etc.). They can see which apps have access to their data and can disable access at any time from the Google Accounts page, the Google Dashboard, the “Buzz" tab in Gmail Settings, or from the app itself.

This initial iteration of the API includes support for fetching public per-user activity feeds, fetching authorized and authenticated per-user activity feeds (both what the user creates, and what they see), searching over public updates (by keyword, by author, and by location), posting new updates (including text, html, images, and more), posting comments, liking updates, retrieving and updating profiles and social graphs, and more. The best way to get started is to dive right in and begin reading the Google Buzz API developer documentation.

There’s a lot more to come, and we expect to keep moving quickly from here. But none of this would be possible without the hard work of everyone participating in creating the protocols upon which Google Buzz is built, so we ask and encourage developers to get involved with the communities behind ActivityStreams, OAuth, and the countless others that we depend on.

And as with any young API, there will undoubtedly be bugs and issues and places where we’ve deviated from what the specifications say, or with what developers may expect. When you see something amiss, get confused by an approach we’ve taken, or just want to comment on our progress, we invite you to update the Buzz API issue tracker and please join the conversation on the developer forum.

With that, we’d like to welcome everyone to the first version of the Google Buzz API. We can’t wait to see what else we can build together.

By DeWitt Clinton, Google Developer Team2013, By: Seo Master