Although I have my doubts about Google, it still doesn’t stop me hypocritically waiting in line to receive an invitation to play with their new toys. So, after a long wait, on Sunday I finally received my invitation to the preview of Google Wave. I’m issuing a “long post alert” now, so you can cancel next year’s holiday if you plan to read all of this at once!

What is Google Wave?

Most people have already heard of Wave, but it’s actually a bit difficult to succinctly define exactly what it is. At its core, it is a HTML5 application, which provides a real-time messaging platform. That sounds a bit drab, but Wave has a lot of interesting possibilities.

Think of traditional e-mail communication – I send a message to you, you read it and reply to me. Now merge that with an expanded chatroom concept. This makes the whole thing more like a conversation.

Instead of a new e-mail message, you create a new “wave” and invite participants. All participants can see, add to and edit the wave. Rich formatting can be used, so photos, and media files can be inserted. Also “gadgets” or Google Wave Extensions can be embedded into the wave. Currently available gadgets include maps, itinerary planner, video chat and even a Sudoku game!

Extensions are add-ons that introduce new functionality to your account — adding them will personalize your Google Wave experience.

Gadgets are shared applications that run within a wave and to which all participants have access, such as real-time games and voting tools.

Google have made the APIs available, so that developers can create their own gadgets and extensions.

Participants can be added at any time during a wave, and have the option of a neat little “playback” function, which shows the evolution of the wave from the first post.

Users don’t have to be online to watch the wave, they can catch up with it whenever they log on, just like traditional e-mail. Unlike traditional e-mail, though, if the user is online and contributing to the wave, they can actually see the other participants’ key strokes as they reply. Google’s rationale is that a lot of traditional chat is asynchronous. You have to wait to fully read another user’s reply before formulating yours. If you can see the reply as they’re typing it, then it’s much more like a normal conversation. Additionally, it might encourage people to think before rashly responding.

Individual posts can be split apart, so that only the relevant bit is replied to, and private replies to wave participants are also supported. So you can have a sort of conversation within a conversation.

If all this sounds a little complex, the beauty of the system is that it’s not! It is actually incredibly easy to create a wave, add participants, create posts and add media. With the installation of the free Google Gears into your web browser, you can drag and drop media directly into a wave. The whole thing is very intuitive.

It is only in preview stage at the moment, and you can see little changes in the interface almost from day to day. Personally, I would like to see an automated playback feature – currently the user has to click on the “next” button each time to see new additions to the wave. When a wave gets large, a lot of clicks would be needed, so automated playback would be nice – without removing the existing functionality to pause, rewind and fast-forward the wave.

I know that they’re working on the functionality to drag and drop media without needing Google Gears installed, but this requires an addition to the HTML5 specification. It’s no problem to install Gears, but it does limit full cross-platform availability.

Will It Replace Traditional E-Mail Communication?

The short answer: eventually (probably). Wave is an interesting development, and has a lot of promise. Google’s decision to promote an open protocol based on Wave will help to develop mainstream acceptance of it as a platform. The Wave Federation Protocol, based on XMPP, is an open standard, and Google even provide an open source client/server to get people started.

As high-speed wireless networks become ubiquitous, the lightweight XML-based protocol will be easy to implement on handheld devices. And, since Wave works both in a traditional e-mail sense, as well as in a collaborative/chat/e-mail-meets-Twitter kind of a way, it’s easy to see how it will take off.

The challenge for Google, though, is how to get Wave to be accepted in a corporate setting. The predominantly Microsoft Exchange-based, “I-must-have-Outlook-on-my-desktop” organisations. Although Wave is innovative and useful, we won’t see a mass move away from traditional e-mail until it can be integrated into an Outlook-like desktop client. Speaking as a single user, though, it will gradually replace GMail for me – when I get a few more Wave users I can communicate with!!

ICQ ist pöse. Warum? Nun ja, es ist proprietär, die Nutzungsbedingungen sind recht fragwürdig und auch sonst funktioniert es eigentlich nie so, wie man es denn gerne hätte. Dateiversand ahoi!

Aber wie das Leben so ist, kommt man einfach nicht drum herum. Zum Glück hat ja schließlich jeder dort mittlerweile eine Adresse, von den ganz hartnäckigen MSN-only Jüngern mal abgesehen (Pest oder Cholera, anyone?).

Und so unterwarfen sich die Nutzer den proprietären Protkollen. Alle Nutzer? Nein! Eine kleine Gruppe von Geeks leistet nun schon seit Jahren erbitterten Widerstand – oder so ähnlich. Jedenfalls konnte das dritte große Protokoll, XMPP (auch Jabber genannt), nie bis in den Mainstream vordringen, auch wenn es sich unter Linux-Nutzern schon lange großer Beliebtheit erfreut.

Einer der geschätzten Vorteile gegenüber MSN und ICQ ist der dezentrale Aufbau des Jabber-Netzwerks, von dem auch reger Gebrauch gemacht wird. Jeder kann seinen eigenen Server betreiben und sich als “Nummer” eine E-Mail-ähnliche Adresse erstellen, mit der er zu anderen Jabber-Nutzern Kontakt aufnehmen kann. Auch Unternehmen wie Google oder GMX setzen für ihre eigenen Messenger auf XMPP und sind daher größtenteils kompatibel zur restlichen Jabber-Welt. Im Klartext bedeutet das: Wer dort eine (E-Mail)Adresse sein Eigen nennt, bekommt auch zusätzlich eine Jabber-Adresse untergejubelt. Wie viele potentielle Nutzer also noch gar nichts von ihrem Glück wissen, kann man sich in etwa vorstellen.

Trotz aller Unterstzützung nutzt der 08/15 DAU aber dennoch weiter sein heiß geliebtes (gehasstes?) ICQ/MSN. Wofür auch etwas Neues, wenn sich das Alte über Jahre bewährt *hust* hat? Mal ganz davon abgesehen, ist die Freundesliste sowieso nahezu vollständig.

Ein wichtiger Punkt: Die Nutzerbasis

Ein Messenger ohne Kontakte macht wenig Sinn – daran ändern auch Google oder GMX absolut nichts. Facebook könnte allerdings, um mal zum Punkt zu kommen, diese Nutzerbasis liefern. 300 Millionen registrierte Nutzer, die prinzipbedingt das Portal intensiv nutzen, sind jedenfalls eine beeindruckende Zahl. Einen internen Chat gibt es immerhin schon über ein Jahr und die Öffnung des Dienstes per XMPP steht kurz bevor. Das könnte der Durchbruch sein!

Mich würde es jedenfalls wundern, wenn Facebook keine saubere Jabber Implementierung liefern würde. In der Vergangenheit haben sie schließlich schon gezeigt, dass sie gewillt sind, neue Techonologien zu fördern und voranzutreiben (z.B. OpenID).

Die Schattenseite ist allerdings nicht zu übersehen: Der überwiegende Teil der Jabber-Nutzer wird sich wahrscheinlich früher oder später an Facebook binden. Die Freiheit, einfach einen anderen Server zu nutzen, würde natürlich bestehen bleiben – die Server-Vielfalt wie wir sie heute kennen, würde sich aber wohl komplett wandeln und neu verlagern, nicht zuletzt zugunsten von Facebook.

Aber hey, zu meckern gibt’s immer irgendwas

Desde mayo de 2008 en Facebook están trabajando para implementar el protocolo XMPP en su sistema de mensajería. Aunque actualmente ya se puede utilizar el chat de Facebook en clientes multiprotocolo, cuando esté totalmente integrado XMPP, permitirá utilizarlo en cualquier cliente que soporte el famoso protocolo que se dió a conocer con Jabber.

Algunos sistemas famosos que ya utilizan este protocolo son Google Talk, Yandex, Live Journal o iChat de Apple, a ellos se sumarán los más de 300 millones de usuarios que aportará Facebook y que sin duda van a convertir a XMPP en el protocolo más utilizado para mensajería instantánea del mundo.

Después de más de un año de desarrollo todo parece estar apunto para su lanzamiento y como se demostró en una reunión de desarrolladores de Facebook durante septiembre, el equipo de ingenieros ya lleva tiempo preparando todo el sistema de servidores para dar soporte al servicio. Según parece, lo último que falta por resolver, pasa por implementar el sistema de logueo.

esto es una buena noticia para todos los feisbuk adictos que conozco y es una buena noticia para mí puesto que a pesar de todo, yo odio el cliente de mensajería de facebook (mis razones son bastante estúpidas por eso ni las pongo) pero el chiste es que lo odio y ahora con la implementación con XMPP sólamente tendré que agregar mi cuenta a Pidgin o Empathy y listo, podré hablar con todos mis contactos del feis.

Vía| Genbeta

Saludos.

For those who don’t know what is Today’s Special. It is an Bot hosted in Google App Engine that provide you with Daliy dose of Quotes, Words, Joke, Horoscope, History and Cricket Score.

Click here to know more about Today’s Special.

Today’s Special Bot was initially accessible via XMPP clients only. But now I have extended it to be an Google Wave Robot.

Now Today’s Special will also be accessible via Google Wave.

For those who haven’t yet tried Today’s Special Bot. It is very simple just add todays-special@appspot.com.  Following are the steps:

1. Start New Wave.
2. Click on “+” sign at the top bar as shown below.
3. Add todays-special@appspot.com

Thats all, now you are all set to use this Robot. As soon as you finish adding you see screen as shown below:

Now type valid command from the list of commands.  For example  “Quotes” and press Done, this will fetch list of Quotes.

The instant messaging world should prepare for a major quake — thanks to Facebook, which seems to be all set to launch a new connection interface that would allow Facebook Chat to work with any kind of XMPP client.

The news of this development was first reported by Mickaël Rémond on the company blog of Process One, a Paris-based messaging startup. “It now seems the launch is close as the XMPP software stack has been deployed on chat.facebook.com,” writes Rémond, who is a leading expert on instant messaging and ejabberd and is an active member of the XMPP Standard Foundation.

About a year-and-a-half ago, Facebook had announced that it would build “a Jabber/XMPP interface for Facebook Chat” and that “users will be able to use Jabber/XMPP-based chat applications to connect to Facebook Chat to” communicate, check their friends’ profiles, and set their statuses.

Extensible Messaging and Presence Protocol, or XMPP, has surely become the de facto standard for messaging and presence. After a big push from Google Talk, XMPP is going to get the next major push from Facebook. The world’s largest social-networking service, with over 350 million subscribers, is about to launch the XMPP connection interface. That will allow users to use Facebook Chat with any XMPP client — whether on the desktop or mobile. A good example of how this works is Adium, a popular open-source IM client that allows you to communicate with disparate IM networks. The latest version of Adium supports Facebook Chat.

Why is this news disruptive? Simple: Until now, in order to use Facebook Chat to communicate, one needed to be logged into the Facebook web site or mobile service. However, if the chat can be accessed on any device regardless of whether you are logged into Facebook’s web site, the usage of that IM is only going to increase. This would, in turn, mean tough times for older IM networks such as AOL’s AIM and Microsoft’s MSN.

To understand why independent Facebook Chat on the web (and on the wireless networks) is disruptive, just take a look at its amazing rise. It was prototyped in January 2007 at a Hackathon and become a real project in the fall of 2007 with four engineers. In April 2008, the service went live for consumers and was available to 70 million Facebook users at the time. As of September, nearly a billion user messages were being exchanged every day with 1GB traffic at its peak, according to a presentation made by the Facebook development team at a conference in Edinburgh in September.

I’ve always been looking for an elegant way of testing custom ejabberd modules.
Tried a couple of ways before but was never convinced. Running tests against a running ejabberd node for example. But it’s not easy, many dependancies, and hard to set up. Mocking modules such as ejabberd_router. But either I hit weird issues, either it’s so cumbersome, I knew I’d never use it again.

But this time, I think I’ve got it.

Check out the cool combination of etap and erl_mock !

It’s on github with more blathering from yours truly.

Photo by Chrys Rynearson

Christopher Zorn, co-founder and Senior Engineer at Collecta,  at BarCamp CHS leading a discussion about XMPP application development.

Wkrótce ruszą otwarte testy nowego komunikatora NK. W związku z dyskusją w sieci i pytaniami, które dostaję via różne kanały internetowe poniżej garść informacji technicznych o NKtalk.

NKtalk jest oparty na XMPP (Jabber) co oznacza, że docelowo istnieje możliwość otworzenia protokołu na zewnątrz NK. W tej chwili trudno jednoznacznie stwierdzić kiedy może to nastąpić ponieważ wymaga to określonego nakładu pracy ze strony działów IT. To co istotne to fakt, że decyzja biznesowa o otwarciu się na zewnętrzne komunikatory nie jest negatywna.

W praktyce oznacza to, że w przyszłym roku będzie możliwa rozmowa pomiędzy użytkownikami NKtalk, Tlen czy GoogleTalk (i innych). Obecnie nie jesteśmy w stanie podać konkretnego terminu otwarcia.

Co ważne, protokół jest praktycznie niezmieniony, poza potrzebami wynikającymi z konieczności dostosowania go do wymagań portalu. Zdecydowana większość rozwiązań zastosowanych w NKtalk jest zgodna ze standardem.

My echo bot has received a bit of attention since my last post.

Add echo@test.collabora.co.uk to your jabber/gtalk friends, and you can see what I mean.

Note that it currently doesn’t automatically restart itself when it goes down. This is so that I can try to debug crashes rather than leaving them unnoticed. If echo@test.collabora.co.uk seems unresponsive, try gabble.echo@test.collabora.co.uk for now, and send me an email. I will try to add a watchdog bot soon, so that we can have a more reliable service, but I’m dancing all this weekend.

I just released the first version of gwt-strophe, GWT bindings for the Strophe XMPP library. Nothing much to say else than it is pretty young, with all that can imply. The project is hosted at https://launchpad.net/gwt-strophe

Our client in Redwood City, CA is in need of a seasoned system administrator and operations engineer to manage, maintain and support multiple environments supporting several different architectures and environments. The successful candidate will have strong exposure to large web site deployments with multiple tiers include web front-ends, middleware components, backend services, data storage systems and 2nd/3rd tier components like caching and search layers.

Requirements:

• 7 years Linux admin experience
• 5 years RHEL admin experience
• 5 years RPM management and admin experience
• 3 years working with MySQL
• Sound understanding of web services and related technologies (HTTP, REST, XML, JSON, etc)
• Experience with Linux web servers (Apache2, nginx, lighttpd, etc)
• Experience with monitoring systems and components (nagios, cacti, etc)
• Exposure to scripting languages such as Perl, Python, etc.

Really nice-to-haves but not required:

• Experience with Erlang
• Experience with Ruby on Rails
• Exposure to Jabber/XMPP
• Exposure to distributed / grid computing
• ejabberd administration and configuration
• Experience with second and third tier services and components like memcached (or like systems), search applications (lucene, xapian, sphinx, etc), etc.

Realistically, these are also nice to haves but not required:

• Exposure to functional programming languages.
• Exposure to the Facebook Platform, Open Social and or other web services and systems
• Comfortable working in an Agile work environment.
• Plays games and occasionally keeps tabs on the gaming world/industry.

If interested, please send us your resume along with the rate per hour, contact number, and availability for a phone interview to raj@mindsource.com.

http://videos.webpronews.com/2009/10/09/collectas-approach-to-real-time-search/

I received a good comment on my second post, where we saw how to write your own XMPP Bot and deploying it on the Google App Engine for Java (GAEJ).

It asked whether one can communicate to another Jabber account from the XMPP Bot hosted on the GAEJ. The confusion arose because I covered the usage of Google Talk, which is an IM client itself. And it looked from my post that you can only use Google Talk as the client to talk the XMPP agent that you wrote.

The short answer is that yes, even if you are using another Instant Messaging (IM) client like Spark or Pidgin, it is possible to communicate to the XMPP bot that you have written and which is running inside the GAEJ cloud.

However, it turned out that I made a mistake in writing the code for the XMPP bot. The Google App Engine XMPP documentation clearly states that you can communicate to any other Jabber ID but it is not possible for their infrastructure to check for the presence of a Jabber ID on another network except their Google Talk network. This is fair enough. By presence, we are simply trying to see if the user is online or not.

So , we had some code in our XMPP bot that we saw earlier, which went something like this. This code fragment was at the very end when we are sending back the echo for our Agent.

if (xmpp.getPresence(fromJid).isAvailable()) {
SendResponse status = xmpp.sendMessage(replyMessage);
messageSent = (status.getStatusMap().get(fromJid) == SendResponse.Status.SUCCESS);
 }

What we are doing here is that we are checking for the presence of another JabberID i.e. making sure that is online before sending the message. This works fine on the Google Network but not on other XMPP Networks like Jabber.org. So for e.g. our bot Jabber Id was gaejxmpptutorial@appspot.com. And if the Jabber Id which is talking to it is someid@jabber.org, then it will not be possible for your bot running inside of the Google network to determine if someid@jabber.org is online or not. As a result of this, the code will never enter the block and the message does not get sent.

So, all you have to do to send the message across to another network is to remove the check for the isAvailable() condition and simply call the sendMessage(…) method.

I have verified this by doing the  following:

1. Used another IM client instead of Google Talk. I used the IM client called Spark
2. I have an account at jabber.org which I used to login as shown below in the Spark IM client:
3. I added gaejxmpptutorial@appspot.com as a contact in Spark IM client.
4. I sent a chat message across to the gaejxmpptutorial bot and got back the echo as shown below:

Hope this clarifies that it is possible to communicate to your bot over XMPP from other XMPP Servers. Let me know if any of you are still having issues and I welcome your comments.

http://labs.dropit.se/blogs/post/2009/10/08/Developer-Lunch-XMPP-BOSH-Strophe-and-the-Real-time-web.aspx

Google Web Toolkit bindings for Strophe, the JavaScript XMPP library, are available at https://launchpad.net/gwt-strophe. I believe it provides an almost complete API coverage, including the PubSub plugin. However, it is quite young and far from being thoroughly tested, hence comments are more than welcome. No release yet, so to get the code, proceed as follows:

bzr branch lp:gwt-strophe

Today is the long-awaited day when 100,000 lucky individuals receive access to an early, but working, version of Google Wave. I hope I am in those ranks! Like many people, I have been reading about Wave, but have not been able to experience it hands-on.

Wave has been a hot topic since it was first shown outside of Google last May. Yet it continues to be quite misunderstood, most likely because it is such an early stage effort and most interested people have not been able to lay hands on the technology.

The confusion surrounding Wave was highlighted for me yesterday in a Twitter exchange on the topic. It all started innocently enough, when Andy McAfee asked:

To which I replied:

That statement elicited the following comment from Jevon MacDonald of the Dachis Group:

I am not a technologist. I seek to understand technology well enough that I can explain it in layman’s terms to business people, so they understand how technology can help them achieve their business goals. So I generally avoid getting into deep technical discussions. This time, however, I was pretty sure that I was on solid ground, so the conversation between me and Jevon continued:

Now, here we are, at the promised blog post. But, how can Jevon and I both be correct? Simple. Google Wave encompasses not one, but several protocols for communication between system components, as illustrated in the figure below.

Figure 1: Google Wave Protocols (Source: J. Aaron Farr, http://www.cubiclemuses.com/cm/articles/2009/08/09/waves-web-of-protocols/)

The most discussed of these is the Google Wave Federation protocol, which is an extension of the Extensible Messaging and Presence Protocol (XMPP). However, Wave also requires protocols for client-server and robot server- (Web service) Wave server communication. It is also possible, but probably not desirable, for Wave to utilize a client-client protocol.

Jevon was absolutely correct about the XMPP protocol enabling server-server communication in the Google Wave Federation Protocol. The Draft Protocol Specification for the Google Wave Federation Protocol lays out the technical details, which I will not explore here. XMPP provides a reliable mechanism for server-server communication and is a logical choice for that function in Google Wave, because XMPP was originally designed to transmit instant message and presence data.

It turns out that the Google Wave team has not defined a specific protocol to be used in client-server communication. A Google whitepaper entitled Google Wave Data Model and Client-Server Protocol does not mention a specific protocol. The absence of a required or recommended protocol is also confirmed by this blog post. While the Google implementation of Wave does employ HTTP as the client-server protocol, as Jevon stated, it is possible to use XMPP as the basis for client-server communication, as I maintained. ProcessOne demonstrates this use of XMPP in this blog post and demo.

Finally, there is no technical reason that XMPP could not be used to route communications directly from one client to another. However, it would not be desirable to communicate between more than two clients via XMPP. Without a server somewhere in the implementation, Wave would be unable to coordinate message state between multiple clients. In plain English, the Wave clients most likely would not be synchronized, so each would display a different point in the conversation encapsulated in the Wave.

To summarize, Google Wave employs the following protocols:

• XMPP for server-server communication
• HTTP for client-server communication in the current Google implementation; XMPP is possible, as demonstrated by ProcessOne
• HTTP (JSON RPC) for robot server-Wave server communication in the current Google implementation
• Client-client protocol is not defined, as this mode of communication is most likely not usable in a Wave

I hope this post clarifies the protocols used in the current architecture of Google Wave for you. More importantly, I hope that it highlights just how much additional architectural definition needs to take place before Wave is ready for use by the masses. If I had a second chance to address Andy McAfee’s question, I would unequivocally state that Google Wave is a “concept car” at this point in time.

Postscript: The heretofore mentioned possibilities around XMPP as a client-client protocol are truly revolutionary. The use of XMPP as the primary communication protocol for the Internet, instead of the currently used HTTP protocol, would create a next generation Internet in which centralized servers would no longer serve as intermediaries between users. Web application architectures, even business models, would be changed. See this post for a more detailed explanation of this vision, which requires each user to run a personal server on their computing device.