Finally there is an update to the Google Wave robot API. In the blog Introducing Robots API v2: The Rise of Active Robots the new features are described.

It is really nice to see that a lot of new features has been delivered. It is a long time since the last release of any updates on the API, so it looked like the development or patching had stopped. But this new release solves many of the problems that have exists. I have written my comments to all to all of the functions.

• Active API: In v2, robots can now push information into waves (without having to wait to respond to a user action). This replaces the need for our deprecated cron API, as now you can update a wave when the weather changes or the stock price falls below some threshold. You can learn more in the Active API docs.
  

This features is really useful for enterprise contexts, where it is required that you will be able to update the wave based on external events. With this features you can get a new Wave, when something happens that you need to react to. From the SAP perspective there is Universal Worklist where all events that you have to process are. With this Wave you can achieve some of the same ideas.

• Context: Robots can now more precisely specify how much information they want to get back from a particular event. If only the contents of the affected blip needs updating and you want to reduce your robot’s bandwidth, then you can specify the new ‘SELF’ context. On the flip side, if you do need all the information in the wavelet, you can specify the new ‘ALL’ context. You can learn more in the Context docs.
  

With this enhancement it will be much easier for robots to interact with the wave, because they can get a much better control of what the data is need in each instance. This will make the development easier because you got the date that you need and it will specify the data you need.

• Filtering: In a similar way, with this new API, the robot can specify what events it needs to respond to, conserving valuable bandwidth — and ignore all those that don’t apply. You can learn more in the Filtering Events docs.

With this function you will only get the events that you need in your robots. Simply create a regular expression and then only the entries matching the expression is sent. This is quite useful if you only want events, when a large number of capital letters is written.

• Error reporting: Robots are now able to register to receive errors about failed operations, such as insertion on non-existent ranges. You can learn more in the Error Reporting docs.
  

This function will make it possible to make better and more stabile robots. The use requires that you work, how the robot should interact when an error is created.

• Proxying-For: Robots can now convey to Google Wave that their actions are actually on behalf of a different user, via the proxyingFor field. For robots like the Buggy sample, which connects with the Google Code issue tracker, this means that the wave can be updated with attribution to users on non-wave systems. You can learn more in the Proxying-For docs.
  

I can see that this function will be really interesting when working with one place to monitor all of your solution. It will also make collaboration with external partners much easier.

With all of this information it looks like the robots have been much more decentralized and acts as regular clients. So in the principle the new features will allow you to create a client to Wave using the robot API and some proxy functionality.

There is still room for improvements in the API. This is the two things that I see that currently are missing.

• Better form handling and the ability to apply styles to the forms, so they don’t look as 90ish.
• UPDATE: This is also possible. Integration with Gadgets, so the robots can update the gadgets with new information. With the Active API is this even more interesting. It is now possible to update the statistic gadget when you get a new expression.

Pamela Fox has created a great presentation describing what how the features connect.

No related posts.

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

I tested quite a bit of different Google Wave gadgets in my christmas calender last month. I tried 40 different apps with a large verity in their complexity and usability. Some of them did not have any useful functions or did not work.

I really liked many of the ideas created in the gadgets and some was really useful. It was fun to see how people wanted to impress with new ideas.

The quality of the gadgets and robot was lausy. Mine included. I believe that many of to my application must be improved. But with the limited option in the robot API hinders making layouts to shine. It also provide a hindering there is a lack of way the gadget/robots can work together. If there was a better way to make the gadgets/robot work together, the layout issues could be solved.

I will say that most of the gadgets except maybe the simpler voting gadgets all require extra work before they can be used by a wider audience. The robots where you need to write commands with # or ! as the only thing in blip, I doubt that my mother will pick it up easily which is required to get non tech savvy users on board.

One key to make it possible to get the robot to function better is to pay the developers. I guess most of the developers of the robots/gadgets I have seen just tried the protocol out of see if they could make something useful. And they can. But to make them look wave-y the gadgets need to look better.

To make the gadgets/robot complete we need to be able to get some better apis and more importantly be able to charge for your apps. Currently it can be possible to charge for the usage of a robot and with some development also a gadget, but it is a pain and will require to much of the user.

I’m therefore looking forward a Wave app store is created. It will be interesting to see if it only supports one time payments or monthly payments and maybe even corporate multi seat licenses. The wave app store will mean that more developers will start with developing programs for Google Wave, making the platform more attractive.

I’m currently only letting my apps be available to my mail list subscribers. We have a new scrum gadget that just need to be published. So sign up to the newsletter and try it out.

No related posts.

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

I had when I first got access to Wave, I wrote a blog about how to create a Wave Robot using Grails. This blog can be read at Graversen.org.

Now David Trattnig has created a plugin to Grails for developing Wave applications. I had to try it out and see how it works.

The first project I tried the plugin on was a failure. I got some error, which I did not think the Wave plugin had created. Just me fumbling around. So I created a new project to see if it was better. The result was much better on the second try. I got a functional robot working without much code.

When you run the commands.

You get all the objects you need to create a robot, which is bacisly just one file as a service. You can then start coding in this file. The plugin automaticly handles the creation of the URL mappings needed for the Robot to work.

In Wave you normaly have to create the capabilities.xml file as a seperate file outsite the code. This is irretating to be working with and you have to make sure to update the file. With this plugin all you need to do is to change the begining of the Robot file to something like.

With this information the cababilites xml file can be created.

The development of the plugin can be performed in the processEvents method. Like the following really meaning full code.

Using this frame work is really easy and takes care of some of the irritating features you always need to use when developing Robots.  It does requires some knowledge of Grails/Groovy.

I have not tested the function for embedding waves, but it should also be fairly simple to do. You should just insert the Groovytag.

&lt;g:waveEmbed waveId=<span>"googlewave.com!w+BmNwtyw5qH.1"/&gt;

No related posts.

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

Extensions are an easy way to distribute you Wave applications. When the user has installed an extension the user can add robots or gadgets just by pressing a button. This is much easier then remembering the URL of the gadget or Robot. For robots it is pretty simple, since you can add the robot to your gadget.

What is even more exciting about extension is they can allow for an app store for Wave applications. It would be very interesting, if you could sell/buy as easy as you can from the Itunes App store. If it was possible just to make applications and then have somebody else to sell them, more developers would be interested in developing applications. That way you don’t need to finance you gadgets with ad words.

I was looking at the blog on How To Uninstall An Extension or Plugin on Google Wave. The blog does not give an explanation on how to install gadgets, so I have been working to find a way to do it. I should just have a look in the getting started wave.

I have been looking at creating my own extension and install them. In the sandbox there was a debug menu, where you can stall the extensions from. In the preview system you needed to find a place the gallery wave (Search for: Extension Gallery). From this wave it is possible to install the gadgets Google has accepted by clicking on a button.

This video shows how the gadget installer and uninstaller work.

I you are a developer and want to test your own extensions you can do it by installing the “Extension Installer”. When this is installed you can install new gadgets from the gadget URL. So this is the way you can test your application, before you send it to the app store. I don’t know you can share the applications with other or they need to install via the developer gadget.

Update: if you want to write an extension your self have a look at  Extension Installer XML creator (for Gadget)

No related posts.

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

In the last post I created a screencast of how a debug session, which showed which annotations is created.

Now I have posted the robot so it is possible for others to start using the robot. This will allow all users to investigate how the annotations work. I hope it will help you to gain some more knowledge on how annotations work.

Simply add the robot with the name BlipDebug@appspot.com to you wave, and start modify your application. Just be careful and not add the robot to any large waves. This robot is quite disturbing and should only be used for testing purposes.

The Java code to the robot is in the code.google.com repository.

The robot is now approved in the sample gallery.

No related posts.

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

Annotations (com.google.wave.api.Annotation) is a key concept to understand, when you are developing robots, how should understand the content of a robot.

I have created a screencast, where I show how the annotations are changed because of the editing.

I have found the following types of annotations.

• user/d/key identifies that the user is on the blib and is in edit mode
• user/e/key identifies where the users cursor is only the from selection counts.
• user/r/key identifies the selection the user has created with start and end. The user will still have his curser at a place in the blip.
• style/fontWeight identify if the selection is bold
• style/textDecoration can be used to add line through
  
• style/color is the color of the selected text
  
• lang identifies the language of a region. There can be multiply different languages in a blip.

There are probably a number of different style markings, which you will have to find your self.

Key is probably a hash of the user address.

No related posts.

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

I was just trying to design a robot that I would like to show for a demo. I needed somehow way to describe how the robot would interact with the user.

As so many other times I found the Whiteboard very useful. With the whiteboard is it possible draw with different colors for each participant. By using this method it will be possible to see the resulting Wave. The resulting wave will give an impression if the content is sufficient.

I would expect that use cases also could be an option, but they would focus more on with what the participants interacted with, not on how the result looked. The use case design is probably still a good idea, to make sure that all interactions are covered,

Designing such an interacting robot, might be involve many participants. It would be idea if the users cold design the resulting wave, by using Google Wave as the collaborative tool. They should probably create a wavelet, they could collaborate on and one where they could sketch the resulting wave.

Do you know of any modeling tools or methods, which could be prove useful for designing robots?

No related posts.

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

In some instances you want to have the robots and gadgets to interact. A scenario where it could make sense is, when the user wants information about a site. The page which could be showed could be the sales report of the customer or some other information which is of interest to the participants.

This tutorial has basis in the Creating A Simple Inline Gadget To Show External Web Applications, which shows how to inline a page into the a wave using a gadget. There is a robot which creates a form for entering the url of the page. When the user press submit the robot adds a gadget which inline the specified url.

First the robot which inserts the gadget.

The robots listens for two event. First the SELF_ADDED which creates the URL form with a text box and a submit button. When the button is pressed a gadget is inserted in to the Blip, with the url of the gadget + the target URL. Probably something should be performed to ensure that the submitted URL is valid and can be sent as a query parameter. Probably a URL encoding should be performed or save the data in the datastorage.

The code is the same in the original blog it has just been placed into a servlet, to make it possible to have parameters inside. It just inserts the query parameter into the gadget XML.

The code can be found at code.google.com.

No related posts.

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

I’m designing an application for Google Wave, which interacts with the user. The following is the considerations that I have for how the architecture of the application works best.

The application that I’m planning on should consist of a Robot which interacts with the user. The other part of the application should be a web application where users can configure how the robot should interact and view status from the waves. There should also be some analytics capabilities. The backend application needs to be rather a little complex to fulfill the requirements.

The most convenient way would be to use appengine, since it is the place that is mostly integrated with Google Wave currently.

Appengine contains a lot of really nice features for building applications. You just created you application and then you don’t need to consider how to scale the application, since this is done by Google. This is a huge advantage and you don’t need to have any resources working with deployment. You can sleep at night, knowing that you cannot do anything to solve problems with the database or the servers. If you are successful and create the application with a lot of growth you just have to pay a little more. You don’t need to use Amazon EC2 or other cloud servers, where you need to scale you application programmatically via the APIs. Spikes in trafic are also handled without any problems.

I will not place my backend application on Appengine, even though I have the advantages listed above.

One problem is the “lack” of support for high performance development languages like Ruby-on-Rails (RoR) or Grails. I have tried to deploy Grails applications to Appengine. There are still some problems with getting all the features working like they do with hibernate. I also ran into problems, where the application worked on the development server, but not on the Appengine because of the whiteliste.

There is also a project for getting Jruby to work on Appengine. It mostly looks like Ruby works with Sinatra, a smaller framework than Rails. I would suspect that there is still some way to go, before the Jruby and Appengine works just as easy as the standalone version.

If it is not possible to use one of these frameworks, development will take longer time. Also the application will be less flexible be more difficult to maintain.

I want to develop the backend application in Ruby-on-Rails, since this is the place, where I have found most resources on how to create scalable applications. The plugins also is of a high quality.

All the developers in the organization are Java developers, so Groovy and Grails would be the obvious choice to learn. I just don’t find the same size of community and quality of plugins. I think we also could have success with Grails applications.

The application that, I planning to building, will have some of analytics capabilities. The Appengine datastorage does not allow summarizations of data like with SQL “select plant, sum(stock) from x group by plant“. Therefore the application should fetch all the data objects and then calculate the sum. The datastorage also have a limit on the number of entries it can return. Thought I read on the Appengine blog, that it was possible to perform queries in parallel, at least on python.

So how do I then plan to make this architecture work? Currently it is only possible to make robots, which runs on Appengine. This restriction will be removed at some point, and the robots can be created directly in the (G)rails application.

But I want to create an application which is ready, soon after wave is release of Wave to the public. So we need to get started already. To make this happen, I think the best architecture is create the deployment like the following.

I’m planning on building the robots on Appengine. The robots have access to the backend data using REST, which should be easy to create in Ruby-on-Rails. We can then use Appengine datastorage and memcache for optimizing the robot. The other alternative is to create a proxy on the Appengine, which sends the posts to our Rails applications.

I need to find a way to get the Ruby-on-Rails application hosted, but there are plenty of resources for this. An even we are optimistic, we will probably not scale to more than 10 servers.

There will also be a problem with how we can do deployment of applications, when we rollout new releases. The release need to be synchronized both to the Rails application on a robot on Appengine.

There will be an issue with finding the right place to business logic in the robots. I’m currently not sure on how this can work out.

I would like to know if you think that I’m on a wild goose chaise with my architecture. Will I have more success with developing the application on Appengine.

No related posts.

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

Tommy Pedersen shared the link to what is coming in the API.

It looks like the developer preview will stop on September 30th, and then we must hope we can get an account on the production system. So we will not float without wave access for a long time.

What is interesting is that Douwe Osinga from Google is sharing, what they believe they can achieve before the end of the developer preview.

The things I think is the most exciting news are the following:

• The Robots can use other addresses that name@appspot.com. That could mean you could have more robots on the same application making the robots tailored to the user. Also we will see that robots will exist on our own servers and not app-engine.
• A better integration between robots in to Wave, so they robot can perform tasks even the wave is not active by a user.
• Gadgets better support for using Google Web Toolkit, will make it easier for everyone (how is not a Javascript master) to make Gadgets. This is probably lower the barrier to create Gadgets.
• OpenSocial integration for both robots and gadgets. That is something that I’ll need to look more into.
• Insert simple HTML into the waves. This is not possible now, so the robots can make some better looking content easy. Then we need to consider using CSS on the document.
• Open source the robot API it does not matter much now, but for the adoption that will probably make things easier.

I’m impressed with the plan Google has created for the development of the Google Wave API. I hope they have made some of the improvements already otherwise they will have a hard time implementing them all.

No related posts.

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