Google wave interim report

I have used waves for a while now and I've had fun implementing robots and gadgets - event though nobody ever appreciated my brilliant JDebuggy so far ;-)

Now it's time for an interim report.

I honor the hard work that all the wave developers spent so far to create this product. To build a browser based realtime application that handles concurrent changes of potentially thousands of users is far from being an easy task. I've worked on a realtime GWT based callcenter client in the last years with a limited number of users (<1000 concurrent callcenter agents) and it was quite difficult to build a robust and reliable browser based application.
You have to deal with the persistent connection limit in IE (that might be the reason why wave is not available for IE right now), have to assure that the application state will be restored when the browser crashes or when the user reloads the page and other problems alike.

Despite of being appreciative of the good work of the involved developers - I think wave has a long way to go until it turns into a useful tool. This is why:

Google wave claim to be a potential combination or even replacement for email, blogging, twitter-like instant messaging services, word processors, photo sharing apps etc.
But I've the strong feeling that these particular services are successful, because they target a very specific problem and deliver an extremely simple to use solution.
People like to use Twitter because they can simply start to type and publish with a single click. Flickr has a specific UI for sharing and tagging photos and provides an API that is focussed on accessing photos.
Blogger is cool, because its focus is on creating and editing posts and lets you easily modify the page layout using a simple template mechanism and css for styling without messing around with the posts.
Google docs is very nice, because you have the subset of word processing power that will satisfy the needs of 90% of the usecases and lets you import and export into lots of document formats.
I could go on with the list, but I think you already got the point.

In contrast to these applications Google wave is a more generic approach.
If you know me, you may already know that I'm not a big fan of generic approaches.
You'll find generic design approaches a lot in software projects where unexperienced software architects come up with a idea like this: "Hey, I've a brilliant new generic approach for our API. We can do everything we want in the future without changing the API by simple passing in a generic Map of objects and get back a Map of objects!"
Of course it is cool and very impressive to have just a single-method API that lets you do fairly everything, BUT: you'll wipe out all the improvements that have been made in software languages over the last decades like compile time type checks, strong typing etc.

But that's a totally different story. Let's get back to Google wave.

In wave you'll find tons of potential usecases - and this makes me suspicious because of the reasons described above. But let's do a reality check for the most important ones:

Email

Everyone uses email, because it is the 21 century replacement for letters. Even though you can abuse emails for simply sending documents or photos, it is generally used as the way to send longer private letters to single or multiple persons.

The content is important and so I personally like plain text email and I hate html emails as they'll cause a lot of trouble because the email client may screw it up.

What about wave?
Right now waves are always styled (equivalent to html emails) and even worse: You are encouraged to add so called gadgets to your text. These gadgets are living pieces of software that may use a lot of javascript.
If you use wave to write an email like letter, you may not be amused that all participants (=recipients) can change the email you've sent. If you'll have a look at your text some days later, you may not recognize it as it might be totally changed by someone else.
You have the chance to use the "playback" feature that let's you go through every single revision, but it is very hard to find the changes made and this playback feature is of course only available in the wave client. If you would access the wave in an arbitrary text editor without playback feature, you'd have no chance to see the documents history.
So you are tied to the wave client to access the mail.
Another problem is that you'll see all the changes that someone is making in realtime. So the private character of an email is totally gone. There is a planned "draft" feature to enable you to type first and send later, but I'm concerned about how this will work out when many people are allowed to edit the document at the same time.

But I don't want to be fussy. Here are my suggestions that need to be implemented to improve the email capabilities of wave. I've already posted some of these suggestions to the wave sandbox, but here we go again:

• Permissions
  To keep the email feeling of being the owner of a document, wave needs to support a fine grained concept of access control. The permissions should directly modify the UI so that only the allowed actions will be accessible.
  You'll need the following permissions to be able to use wave as an email like application: 
• READ 
• EDIT 
• STYLE_TEXT 
• DELETE 
• ADD_GADGET
• REMOVE_GADGET
• ADD_PARTICIPANT 
• REMOVE_PARTICIPANT 
• ADD_ROBOT 
• REMOVE_ROBOT 
• CREATE_BLIP 
• DELETE_BLIP 
• CHANGE_PERMISSIONS 
• COPY_TO_NEW_WAVE 
• PRIVATE_REPLY
• CHANGE_TITLE

So if you'll use wave wave to write a plain text email to your best friend, you'll:

1. Create a new wave
2. Write the text (to write text before adding participants is the only way to avoid them to watch you while typing)
3. Add your friend as participant
4. Grant your friend the permissions to read and private reply. If you'll not grant the STYLE_TEXT permission, you friend should not be able to create a reply with styles text in it. As you'll not grant the EDIT permission your text will be untouched in the future.

Right now there are no such permissions in wave. And there is no way to add permissions on a participants level.

• Templates
  Of course it would be unacceptable to keep the user in charge of going through all these steps just to write an email. In wave you'll also need a way to create wave templates that will automatically add certain permissions to the participants and add certain robots.
  An email template would automatically add the spell checking robot and would grant the proper permissions to every participant added.
• Default permissions per contact
  Some contacts may have certain roles. So if you have a certain coworker to create shared documents, you automatically want to grant him the EDIT permission if he is being added to a wave. To find out if the permission per contact overweights the template permission set there needs to be a concept like GRANT, GRANT_ALWAYS, DENY, DENY_ALWAYS to calculate the resulting set of permissions per contact.

  
Word processor
When it comes to collaboration on a shared document this is one of the strengths of wave. You'll see the changes of the participants in realtime. It is not yet foreseeable how wave will relate to Google docs in long term.
There is currently no support for existing document formats and the text style capabilities are very limited. So right now it looks as if wave would end up somewhere in between docs and email.
Again here are some suggestions, how to improve wave to deliver a better user experience when it comes to document collaboration:

• Improved playback history
  Right now it is very hard to follow the changes made to a wave. You are able to step through the document history, but it is difficult to find the changes made in each revision. This can be improved:
  IntelliJ, Eclipse and latest dev build of Chrome search have it: Colored indicators in the scrollbar to jump directly to certain positions in the document. This would be extremely useful in conjunction with the playback feature: Mark the modified positions of the document and let the user directly jump to these positions to be able to track changes made in each step.
• Annotations
  Modified parts of the wave should be annotated. There are already proven ways to show annotations in OpenOffice and other office suits. A short-term improvement would be to display the author when hovering with the mouse over the text.
  Google docs offers a minimalistic but useful revision compare mode. If would be nice to have such a history view in wave to compare playback steps.
• Create as new doc
  Instead of being able to create a fresh wave from an existing one it would be very cool to be able to create a Google doc from a wave. So you could start brainstorming in wave and finishing the document in Google doc and don't need to implement a full blown word processor in wave.

I'll try to post my suggestions to the other usecases, but that's it for now. Just found an interesting post addressing similar issues:

http://jungleg.com/2009/06/04/googles-wave-doesnt-look-like-a-tsunami/

floreysoft is back from Google I/O

Yesterday we returned from our trip to San Francisco where we joined the Google I/O.

As I'm suffering from Jetlag and woke up at 4 am I'll use the time where the world is still asleep to let you know what we are currently working on:

Google wave

We've been invited to join the so called "Google wave hackathon" at the Google office in Mountain View. The Google folks explained the new product and the API that developers can use to extend it.
The people at the hackathon received the first accounts on the developer preview of Google wave to play around with the API.
You can create some server side extensions (robots) and client side gadgets to add additional features.
After some experiments I figured out that it might be very useful to be able to create and test robots in the local eclipse environment instead of uploading the robot code to appengine to test the code. Also it was a little bit 80's like to not being able to debug the code right in eclipse.
Instead of complaining I've spent some hours in the hotel room and hacked on a debugging framework and finally got it working!
To develop and debug robots in your local environment you have to download this tiny jar file containing the local debugging proxy server.
You can specify a unique name for your robot when launching the jar:

java -jar wave-debugger.jar myfancyrobot

Now you can create a new wave and simply add the JDebuggy robot (jdebuggy@appspot.com) to it. This robot will add a gadget where you have to enter the same unique name to start debugging. There is a tab where you can specify exactly which events should be forwarded to you local environment. If you enable the DOCUMENT_CHANGED event you'll get events for each key you are typing so this will cause a lot of traffic and makes debugging quite hard.
You can change the settings and start and stop debugging by using the gadget and you can test your robot by using the wave as all events will be forwarded to your local environment.
If you are interested in the technical details of the implementation I'll try to explain it in a few words:
It has been a little bit tricky to get everything in place as I had to fight with several restrictions:

• If you create a robot by extending the AbstractRobotServlet the servlet input stream will be consumed by this servlet and is not accessible later on to forward it to the robot that should be debugged. So I had to create a copy of the input and output streams to be able to read it twice and send back the data of either the JDebuggy robot or the robot to be debugged. This sounds easy but the I had to write some mockup classes to fake the ServletRequest etc. 
• The basic idea was to call your local servlet on your machine to trigger the robot servlet right in the eclipse environment. But your local machine is most likely not visible and reachable from the net as you may be behind a router with dynamic NAT. So I had to find a way to create the connection from your machine to a server. This could be done by polling for new events but this would make it very hard to simulate synchronous communication with the wave server. So I chose creating a open socket connection between your local machine and the server.
• Unfortunately and for good reason Google appengine will not tolerate to create threads, sockets etc. So I had to find another way to let you establish a socket connection between the two endpoints. I've created a debug proxy server on our floreysoft root server and forwarded all requests and responses from app engine to it after debugging starts. So I now could use all the dirty tricks to get it to work (server sockets, threads etc.).

So when you start the local wave-debugger.jar you'll establish a connection to the floreysoft debug proxy server and register with the unique robot id. JDebuggy will then consume the wave requests, evaluate them and eventually forward it to the floreysoft proxy adding the unique robot name to the request.
The floreysoft proxy will distribute the incoming requests to the proper socket to be able to debug many robots at the same time.