The great folks over at WithWaves have added a contribution to the Google Wave community by providing their internal tools to the public to help others build Google Wave extensions. You may remember the WithWaves guys from our Developer Spotlight: WithWaves post. They build some really great EBay & Amazon extensions.

Using their extension generator you will get the following:

Runnable Hello World project ready to be modified and added to a Wave

Spring integration in your robot / gadget back-end project compatible with Google App Engine

Ant tasks to test your gadget locally and deploy to App Engine from the command line

Access to our API core components, including an open source implementation of Named Entity Recognition for blips based on theAlchemy API

Gadget server handlers for communication from your gadget to the server with JSON / Spring

jQuery integration for your gadgets

Common gadget JS classes to handle Wave callbacks and state modifications

Simple Wave JS emulator that allows you to view your gadget locally for testing HTML/JS/CSS before deploying

Locale based language support for your gadget

Metadata to expose your robot / gadget as a extension installer

Eclipse / Google plugin ready project to run and update to app engine from Eclipse

They provide the following information and video to guide you through the process:

If you already have Java, Ant, Maven and the Java App Engine SDK installed, simply execute the following command in your console:

mvn archetype:generate -DarchetypeCatalog=http://mvn.withwaves.com

After entering the values for your project, you will have a running Google Wave robot & gadget ready in no time.

Use the same command to generate extensions in the future and you will have the option to enable new features as we release more extension generators.

Check out the videos below for a demo creating a simple “Hello World” robot and gadget, and optionally running it inside Eclipse and the Google Plugin for Eclipse.

WithWaves Extension Generator Demo from Derek Punsalan on Vimeo.

If you need more information about getting started with Eclipse and the Google Plugin for Eclipse see our post and detailed powerpoint presentation that we used at our Google Wave Hackathon we held in October.

If you need more information about Java, Ant, Maven and the Java App Engine SDK you are going to have to visit the links provided for those products and do a little reading. If you are a complete beginner, you should probably be prepared to dedicate a full day to getting yourself started.

Hope any of you wanna-be developers find this useful. It should help you get started much quicker with a product. Look forward to hearing from anyone who found this useful. Also, drop a thank you off over at WithWaves.

Leave a comment below with your thoughts, we love hearing what your thinking. Have you used their tools?

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

In May 2009 at I/O 09, was launched to much deserved fanfare. A lot of the initial prognostications declaring  to be a replacement for just about everything and as an important an invention comparable to “the wheel” have, thank god, died down. In fact, because of much of the initial nonsense calling it a Twitter, Facebook and e-mail replacement (Google did that one) have turned many off of the pre-Alpha Preview version.

Of course, readers of this blog know that while  may not be ready to replace anything just yet, it still holds unbelievable promise for transforming how we currently collaborate on everything from projects and documents to meetings and online shopping. If we take the current definition of Web 2.0 to be associated with web applications that facilitate interactive information sharing, interoperability, user-centered design and collaboration on the World Wide Web. Then,  is the first true web 2.0 application for business.

That being said, the current preview version (pre-Alpha) of , although functional and gives folks an understanding of the product, is starting to do more harm than good. I understand the reason for the early preview: trying to understand server load problems, uncover shaky code and desperately searching for use cases. But the time has come to show that this application/protocol is much, much more than a glorified chat program with a few neat extensions. I think 2010 will be that time.

Thus, my TOP 10 IMPROVEMENTS for GOOGLE WAVE in 2010:

10. Developmental Timeline. I blogged about this extensively in another post recently titled: Where is Google Wave Going? In that post I laid out the following:

• Develop your Google Wave strategy for the way ahead.
• Release your vision of Google Wave and your vision for what you will be further developing for the product.
• Release some milestones that you have for the product.
• Talk about document support and how it will evolve and when you think it will be available.
• More info about a robot/gadget store would be wonderful.
• Outline a clear business support model. – Accreditation and/or certification credentials, building an appliance, etc, etc

9. Delete a Wave Permanently. The closest thing that you can now do is send your Wave to the trash. However, when you click on “All” you still see that Wave. It lives. Moreover, regardless of being the owner I cannot permanently delete a Wave, everybody else still has that Wave. I am only putting it in my trash. There is currently no delete. The owner should be allowed to delete the Wave. In business I don’t necessarily want to have collaboration work live forever. That would be another post by itself as to why that is a bad idea, but suffice to say the reasons are not nefarious….just good business practice.

8. Integration of Moderation Features. This was a topic of another post titled: Google Wave Etiquette – Moderating Your Wave. This post talked about the good work done by those currently using Google Wave to put in place a set of rules that help ensure we have a civil real-time collaborative discussion or workgroup, that obeys certain rules or customs. These ideas are good ones and Google needs to take a hard look at what so many are adopting for their Waves and make it a functional part of the Google Wave client.

7. Google Wave Client Code Released. Ok Google, thanks for the Federation protocol being open-source and all. Great, wonderful! But without a really slick client…federating is kind of worthless. The client is the great part. Now, one could develop a client but that would take great effort (for a good one) and with nothing released regarding Google strategy (see number 10) I could be wasting my time and money. Thus, if they want more people to actually federate with a meaningful Wave server they need to release the client code.

6. Google Groups Integration. Well, they claim to have integration with Google Groups. But,…have you tried it. I dare you. Come back and let me know how long it took and how it worked out for you. Enough said. Fix this!

5. Inbox Management. I spent a quite a bit of time thinking about this before deciding to add it to the list, let alone make it in the top 5 improvements. There is a lot of Waves out there that describe hints of  inbox management with Google Wave. My problem is that it is way to similar to the email inbox. I think some real thought needs to given to this problem to make it work for Wave. I don’t think just replicating an email inbox management solution works. One simple example to highlight this point would be the problem with finding a reply to Wave. Somehow that should be evident from your Inbox. This needs work and a new approach to looking at this problem, I think.

4. Draft Typing. The box is there but the functionality is still not available. I expect this will be an easy one for 2010, but it is a big one. Depending on how sensitive something is, this becomes critical…as in, I won’t use Google Wave for this correspondence because I don’t want anybody seeing what I’m writing until I am finished.

3. Owner Only Remove. The owner of a Wave must be able to remove participants from that Wave. Let’s say someone inadvertently gets added to a sensitive Wave they were not intended to be part of. The owner needs to have the ability to control his Wave and remove folks as he see fit.

2. Owner Only Invite. Keeping with same theme as the above improvement. There needs to be a function where the only person who can add a person to a Wave is the owner. It doesn’t need to be a default setting but its needs to available otherwise real business will not take place on Google Wave. If anybody can be invited into any Wave by anybody…I will share nothing of relevance with anyone.

1. Document Collaboration. The Holy Grail for Google Wave. I have written many posts, the latest titled: Google Wave Preparing to add Document Collaboration. This improvement is a must and needs to happen sooner rather than later. The problem with Google Wave right now is that nothing really serious is happening on it. Folks go looking for a Twitter like experience and find it lacking. Folks go to do collaboration and find that it is extremely limited because no office suite is integrated. Google Wave’s real power will lie in document collaboration and they must introduce it in the early part of 2010.

I, for one, will be at I/O 10 this year and hope to see Google unveil all of the improvements I mentioned above. So, ““

Did I miss something that is tops on your list? Leave a comment on what you think should have made the list, or just leave a comment on the current list. We love hearing your feedback.
Happy New Year!

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

This month’s edition of the “Developer Spotlight” highlights the efforts of two developers: Laura Stolp and Pieter van Ginkel, both of whom you can find on SourceForge.

If you are not familiar with SourceForge you are probably not a developer. SourceForge is the world’s largest open-source development site that provides numerous free services to manage your project, including collaboration software development tools…like CVS and Subversion.

The application that Laura and Pieter developed is called Google Wave Notifier. They describe the application as follows:

The Google Wave Notifier is a Windows application that alerts you whenever you receive a new Wave. After you download the Notifier, an icon will appear in your system tray to let you know if you have any unread waves.

The Google Wave Notifier has the following features:

• Get real-time updates of new and changes Waves;
• See the last reply to an unread Wave;
• Quick access to your last five unread Waves;
• Automatically updates to the newest version;
• Easily browse to an unread Wave or your inbox.

The Google Wave Notifier installs itself into your system tray.

After logging on, the Google Wave Notifier will automatically inform you of new Waves or replies to existing Waves. When a new Wave appears, a pop-up will be displayed and the system tray icon will get an overlay icon to indicate you have an unread Wave.

Clicking on this pop-up will automatically open your default browser with the new Wave already displayed.

When there are unread Waves, the system tray icon will get an overlay icon to tell you this. Clicking on this icon will give you easy access to your last five unread Waves.

When the Google Wave Notifier starts, it queries you for your Google Wave credentials.

I have tried this application on my Windows machine and have to say that Laura and Pieter have done great work with this app. It works exactly as advertised and is extremely useful. Hopefully, this functionality (if not this app itself) is something Google will make standard in upcoming releases. But, don’t take my word for it…read all the great reviews this app has gotten.

Congratulations to Laura and Pieter as our December “Developer Spotlight” choice. If you are familiar with this app please provide some user feedback below. If you are new to this app…give it a try…then please, come back and tell us about your experience.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

In Part 1 – 7 Advantages of  XMPP we discussed some of the strengths of XMPP. In this second part of our XMPP Mini-Series we will concentrate on how Google Wave uses XMPP. Of note: this particular part has drawn a lot of attention in the blogosphere lately, based on an article which claimed that Google had developed a “full-featured XMPP Client”.

I hope to make is clear in this article that Google has not, nor do they claim to have, developed a XMPP Client. Although, it is easy to see how one could jump to that assumption given that what you see on your screen looks and feel like XMPP. Moreover, I don’t think the comment deserves the pedantic scrutiny that it has received. In fact, I thought the post was very well written and very clear describing the architecture and clearer with the point it was trying to make: that XMPP is a great tool. That being said, how does Google make the magic happen.

The best explanation can be found in a very short article, by J. Aaron Farr, titled Wave’s Web of Protocol. The diagram below comes from that post and is offered freely by the author.

by J. Aaron Farr

This diagram is the best I have come across to date and I think very clearly outlines the protocols used here. Thus, the following protocols and APIs being used by Google Wave are:

• Federation Protocol         –  XMPP
• Robot Protocol                 –  JSON
• Client-Server Protocol      -  As defined by the GWT
• Gadget API                       –  OpenSocial
• Wave Embedded  API       –  Javascript

Now the problem is that only the Federation Protocol is defined. The Robot and Client-Server Protocol are not. The reason for that is because, according to Joe Gregorio in a Google Groups – Wave Protocol FAQ

The focus of our open source and protocol work at this point is on the federation protocol, which is critical for getting inter-operable server implementations, that is, for allowing many other people to build Wave servers and have them interop with each other and with the Google Wave server. We have definitely heard the requests for defining a client-server protocol, but at this time the team doesn’t have the time to put into such an effort.

What is clear in the diagram above is that Google only uses XMPP in the federation protocol, and the federation protocol is only used for wave server-to-wave server communication. The Wave server itself is a OpenFire Server with a Google Wave Extension. Then using the GWT you build your client to speak with that extension. How it does that is pretty much wide open to whoever is building the Wave Client.

So why is it clear that the client is not XMPP. Well, if I have a new wave client, let’s say a desktop based client, I have no way to communicate to Google’s wave server. I have to host my own server, with its own private client-server protocol. Then I can federate with the Goole Server via the XMPP protocol.

At the XMPP Standards Foundation page they list the current XMPP clients and link to a ton of other information about XMPP. The clients listed , in fact, look and feel much like Google Wave does: a XMPP Client. But it is not, many folks have made some clients for their own FedOne Server implementations that act and feel like Google Wave’s Client (see my PyGo Wave post) and their clients are not XMPP, they are clients that have been built with GWT. The fact that is not defined by Google will mean that the argument will continue. But in my mind, it is quite clear that building your server and your client is a different development effort.

I keep saying that I will be building my own server soon. That will now happen in the week after next as my lab space has finally become available and the equipment is being moved and set-up next week.That means I will be putting into practice what I am preaching here.

So, all that to say that Google uses XMPP for Wave Sever-to-Wave Server communications which is accomplished by adding a Google Wave extension to a OpenFire Server. Many folks have also done this using other XMPP servers.

Part 3 of this mini-series will focus on XMPP security.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

There has been a lot of discussion in many blogs lately reference Extensible Messaging and Presence Protocol (XMPP). I thought it would be helpful to start a small blog-series about the things you should know about XMPP. The first part of this series will be a list of XMPP advantages. This should put in context why Google choose XMPP as its server-to-server protocol. Consider these seven (7) advantages (extract from O’Reilly: XMPP The Definitive Guide):

• XMPP is proven. Over 10 years of development has resulted in a stable, widely deployed, seriously tested, Internet-scale technology, with dozens of interoperable codebases, tens of thousands of deployed services, and millions of end users.
• XMPP is secure. It provides built-in support for channel encryption and strong authentication, inherent resistance to many forms of malware, a diverse ecosystem of implementations, a decentralized network without a single point of failure, and significant deployment at some of the most security-conscious financial organizations and government agencies worldwide. Work on more advanced features (such as user-friendly end-to-end encryption) continues so that XMPP will be even more secure.
• XMPP is decentralized. Unlike standalone communication silos, XMPP technologies are deployed in a decentralized client-server architecture with an unlimited number of servers. Any person or organization can run their own XMPP server and connect it to the rest of the network using standard Internet infrastructure such as the Domain Name System (DNS), and certificates are freely available through the XMPP Standards Foundation (XSF) to enable secure federation of XMPP traffic.
• XMPP is extensible. Because XMPP is at its core a technology for rapidly delivering XML from one place to another, it has been used for a wide range of applications beyond instant messaging, including gaming, social networking, Voice over IP (VoIP), real-time collaboration, alerts and notifications, data syndication, geolocation, intelligent workflows, machine-to-machine communication, and custom applications.
• XMPP is scalable. The “push” model of information transfer used in XMPP solves serious scaling problems associated with traditional HTTP-based polling approaches; as a result, it enables you to build applications that were literally im- possible until now.
• XMPP is a standard. The core aspects of XMPP have undergone rigorous public review within the Internet Engineering Task Force (IETF), and extensions to XMPP are published in an open, developer-oriented standards process run by the XSF. This approach has resulted in strong technologies that can be freely implemented under any licensing terms, from open source to shareware to proprietary code.
• XMPP is a community. Open standards, a large number of software products, and a communications network are all good, but the “secret sauce” of XMPP may be its vibrant and friendly community of technologists, developers, open source projects, commercial software companies, service providers, and end users. This community is committed to working together to solve problems and build great new applications.

For these reasons, Google is using XMPP in the Google Wave architecture. For more information visit XMPP Standards Foundation .

Part 2 of this Mini-Blog series will focus on how Google Wave uses XMPP.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.