- monthly subscription or
- one time payment
- cancelable any time
"Tell the chef, the beer is on me."
We've just wrapped up day 3 of this week's Wave Protocol Summit in San Francisco. Developers and industry partners have gathered from all over the world to discuss the architecture of Wave, opportunities for use in enterprise, government, and consumer technology, and the future of the open source project. The last few days have included a great mix of architecture presentations, technical discussions, and interesting demos using Wave technology (WaveLook, Novell Vibe, Wave-vs.net, and others).
Since the Wave in a Box announcement in September, progress has been rapid. We've recently added:
You can keep up to date by following the Progress Reports wave.
As a reminder, we'll continue running wave.google.com at least through the end of the year. We've also recently introduced a wave export feature. In addition, we're working on ways for you to access waves through Google Docs and we hope to share more on our progress soon.
If you're following along from home, we'll be sharing videos following the event -- but please join us in the Wave Protocol group.
The Wave in a Box project is shaping up well and we're now posting regular progress reports to the group forum (the most recent is here). We've also created a list of starter projects, easy tasks for developers to get started contributing to the codebase. You can chat with some of the Wave engineers at the upcoming online office hours (in Google Wave). The next one is on Monday (Tuesday down under) - details are in the forum.
To bring the developer community together we are hosting a Wave Protocol Summit in San Francisco, November 2010. Through the summit we aim to grow the Wave developer community, share technical knowledge, and discuss the future of Wave technology and its community. The summit will be targeted towards technical people interested in using, contributing to, or building on Wave technology. Content will include:
The summit will be three days of talks and discussion (November 8 - 10) followed by two days of coding (November 11 - 12) on Wave in a Box and federation. We're still working out the detailed schedule, so stay tuned to the forums for further details (and give your feedback).
If you would like to join us, you can request a seat (due to capacity constraints, we'll confirm your seat in the coming weeks). To help improve the summit, please also suggest or request session content of particular interest to you.
In the meantime, see you on the forums!
We will expand upon the 200K lines of code we've already open sourced (detailed at waveprotocol.org) to flesh out the existing example Wave server and web client into a more complete application or "Wave in a Box."
This project will include:
Since the beginning, it has been our vision that the Google Wave protocols could support a new generation of communication and collaboration tools. The response from the developer community to date has been amazing and rewarding. Even more so now, we believe that developers and other projects are a critical part of this story.
While Wave in a Box will be a functional application, the future of Wave will be defined by your contributions. We hope this project will help the Wave developer community continue to grow and evolve. We'll discuss more technical details of our plan on the Wave Protocol Forum, which is the best place to keep up with the latest progress on the open source project and learn how you can contribute.
Posted by Alex North, Software Engineer, Google Wave team
Every so often, I leave this beautiful city of Sydney, Australia and depart for foreign lands to meet developers from around the world. This time, I'm heading to the states and dropping by two GTUGs (Google Technology User Groups) to talk about Google Wave and the APIs:
After the GTUG talks, I'll also be swinging by the HTML5 GTUG campout in San Francisco, setting up waves for the teams to document their progress and ask questions.
If you're in the area, I hope to see you there!
A few weeks ago, we released a new feature in the data and robot APIs: threads. This feature means that developers can render threaded waves in alternative clients and export waves to other formats while retaining their true structure. It also means that I can finally use the InfoVis Toolkit, in order to visualize the threads in a wave as a structured tree.
To create the visualization, I started with the code for the Inbox Checker sample, a Python App Engine app that asks a user to authenticate (via OAuth), and then shows them their inbox and any wave they click on. I modified that app to output JSON instead of HTML for each wave, and I piped that JSON into the SpaceTree class from the toolkit.
Here's an side-by-side example of how a wave might look like in the client, and what it looks like as a SpaceTree:
You can try the app out for yourself here: Wave Visualizer. After granting access to the app, you can click each of the waves in your inbox and browse the tree for it. As you mouse over each blip, you'll see a snippet of the content of the blip in the tooltip. When you click on a blip, you'll be taken to that exact blip in the Wave client, utilizing our other new feature: blip linking.
(You can also try out the "Timeline" view, which shows the sequence of blips over time, using the Google Visualization API).
This app shows off one of my favorite features of Wave - flexibly structured conversations. Some waves are very flat long trees, and others are wide and deeply nested, and they are all made possible by the Wave conversation model. And now, thanks to the new Wave data APIs, apps like this are possible.
Enjoy playing around with the visualizer, and if you have any questions about building apps like it, stop by the Wave API forum and let us know!
As part of my Google I/O talk on "Anatomy of a Great Extension", I talked about the optimal look & feel for Wave gadgets. On one hand, if your Wave gadget is based off an existing website, like the 6Rounds gadget, then we recommend mimicing the UI of your website inside the gadget, so that your existing users feel like they're using an extension of your website into Wave. On the other hand, if your Wave gadget is independent and designed purely for Wave, like many extensions in the gallery, then we suggest mimicing the UI of the Google Wave client itself, so that users feel like the gadgets fit inside their environment, and so that waves with multiple independent gadgets look cohesive. To make that easier for developers, we've introduced a new feature to the Wave Gadgets API, the wave.ui library, which makes it easy to turn your gadget elements into wave-styled elements.
You can then call makeButton and pass in the anchor element:
<script> wave.ui.makeButton(document.getElementById("button")); </script>
The wave.ui library also offers the loadCss, makeDialog, and makeFrame methods, and will expand to include additional methods as needed by developers.
For examples of gadgets using the new wave.ui library, check out the Flammard bible bot, which uses makeFrame for a multi-tabbed interface, or the Google Maps gadget, which uses makeDialog for a welcome screen and makeButton for the info window buttons.
As usual, please let us know in the forum how you're using this feature and if you have any questions.
As soon as Google Wave was released and I had an account, I wanted to write a Wave Gadget. I believe Gadgets are one of the strengths of Wave because they let you add a structured component to an unstructured communication flow to make things more efficient. For example, a simple date picker Gadget can be added to an event-planning wave, and instead of people having to go to a separate site and communicate their date preferences manually, they can do the date-selection in the wave, and all of the information is stored in a single place. There are many situations like this where gadgets can add structure and keep related information together.
The cobogwave library makes it very easy to build gadgets for Wave. Just like the iGoogle GWT Gadgets API library, it defines a Needs interface: NeedsWave. By implementing the interface, you can make your gadget code Wave-enabled. Or, you can simply extend the WaveGadget class for the same effect.
GWT developers are accustomed to work with handlers, so the cobogwave library provides much of its functionality via handlers. For example, you can register for the ModeChangeEvent to be notified when the user changes from playback to edit mode, ParticipantUpdateEvent when a new user is added or removed to the wave, and StateUpdateEvent when the gadget receives a new state. The cobogwave library also has support for experimental functionallity in the Wave Gadget library, like the Wave UI Widgets Button, Frame and Dialog.
Recently, I was involved in the latest release of the gadgets support in the Google API Libraries for GWT. In the new version, it's much easier to implement RPC calls to your own server, and this method also works for Wave Gadgets.
Here's a sampling of diverse range of gadgets that developers have built using the cobogwave library:
When I heard that Australia was going to have its very own PyCon, I knew I wanted to give a talk. While working on the with the Wave APIs over the last year, I've gotten to the point where I'm using the Python client library on a daily basis, and I've learnt a lot about Python from our library. I wanted to give a talk that would be interesting both to Wave API developers and to Python developers and would force me to dig deeper into the depths of our client library.
So, I presented a talk called "Wave Robots API: Behind the Scenes", with the goal of showing how we used Python to abstract on top of our HTTP API. I started with an overview of Google Wave and a quick look at Wave's core technology — the conversation model and operational transformation algorithm — so that everyone in the room would be comfortable with me talking about blips, wavelets, operations, and the like. Then I went deep into the robots API, explaining the JSON-RPC protocol between the Wave server and robots, and showing how the Python client library serializes the JSON into Python objects, how it lets developers register for events, and how it signs outgoing requests using OAuth. I then explained how we designed the client library to be hosting-provider-agnostic, and live demoed a robot that I created using the Django framework on a slicehost node. I finished with a summary of the most important features of the client library — versioning, automation, authentication, flexibility, and being Pythonic.
But, hey, if all that sounds interesting to you, you don't have to read about it -- you can watch it! Check out the video here, and the slides here. If you have any questions after watching, just head over to our Google Wave API forum.
David Crane is an external Wave developer, involved in the development of the Debatewise extension. We've invited him to post on this blog to share his vision for an open source project.
A few months ago, the Google Wave team open-sourced the code underlying Forum Botty, the robot that is powering the Wave API forum. We want to continue developing this code base into a powerful and generic extension for running forums in wave, and we're hoping that other developers like you will join us in this project.
Google Wave offers a number of benefits over traditional forum software, with just its native functionality. However, by incorporating some of the tried-and-tested features from forums into a robot, we could turn Google Wave into the ultimate platform for forum-based discussion.
A forum could be a killer app for Wave. It’s a tool that people already use in huge numbers for specific purposes, are used to keeping separate to their email, and will dip in and out of as required. Wave is similar enough for them to jump in quickly and different enough for them to get, and be hooked by, the benefits. A forum removes the need for people to find things to use Wave for and means they could use it even if none of their friends did. Wave could enhance and improve upon some of the most important features of a forum and through acclimatisation, will encourage them to use it for a world of other purposes.
There are three specific areas we believe need developing
Goal: Allow people to coalesce around a subject of their choosing and help them find Waves of interest
Tasks: Group waves around subject areas. List the following alongside each Wave title: the total number of blips in the wave (including read/unread), total number of views, date/time of last post and who made the post. Later add ways of rating, sorting and categorising the Wave.
Goal: Encourage and reward participation in the conversations
Tasks: Add karma mechanisms, applause and trophies so Waves, blips and users can be rated. Incorporate tiered participation levels and privileges (eg StackOverflow).
Goal: Develop trust mechanisms so people can determine who to rely upon or ignore
Tasks: Link waves with Google Profiles (or other profiles), display the user’s trophy cabinet, list all posts by user and their ranking in the community
This project is organised by Debatewise.org, a non-profit debating web site whose goal is to be the Wikipedia of debate. Anyone can create a debate on any subject they like and anyone can edit and strengthen that debate. In this way and over time the debates become stronger, more definitive and an ever-greater resource for anyone looking to make up their mind.
If you're interested in joining the project, please wave me at firstname.lastname@example.org.Posted by David Crane, Debatewise
As you may have heard before, the Google Wave Federation Protocol is an emerging open protocol for improving communication and collaboration across the web -- not just in a single product. To further propel the community, as part of Google I/O, we open sourced another significant chunk of Google Wave production code (now totaling more than 200,000 lines of code released), including: the in-browser rich text editor, the wave model, and the concurrency control mechanism.
This code release introduces a simple web client for FedOne, which enables you to bring up your own browser-based client running against the FedOne backend, which can then federate over to WaveSandbox.com. The web client communicates with the FedOne server using an emerging WebSocket-based client/server protocol, with the initial documentation in the whitepaper under review. There is even work going on to make an Emacs client for wave using this emerging client/server protocol. To get started with your own instance, please read a recent forum post: exploring the simple web client, and you may also be interested in reading the wave model code walk-through.
There is a growing community of wave providers building on wave technology and the Google Wave Federation Protocol, including SAP StreamWork (demo below, and you can read more about SAP StreamWork and the wave protocol), Novell Pulse (here's a demo), ProcessOne's OneWave, wave-vs.net, and AboutPeers.com. The US Navy also put out a call for proposals earlier in the year (Navy Wave RFP [PDF]). Additionally, there are several open source projects in development as well: PyGoWave, QWave, ARWave, and Ruby on Sails.
Here's a video showing SAP StreamWork federating with WaveSandbox.com:
This is all driven by the desire to let users work together no matter what system they may be using. For more information about building your own wave provider, feel free to check out the session video and slides from Google I/O 2010.
Please join us in the forum if you'd like to get involved.
Posted by J.D. Zamfirescu, and Anthony Baxter, Software Engineers, Google Wave
Back in April, we ran a challenge together with Mashable, asking developers to make fun and useful extensions. We saw a lot of great extensions come out of it, like WaveTube, Poker, Wave Transformer, and more. Now, I want to take some time out to explain how an open-sourced Wave robot made it possible to run the contest entirely in Wave, from the submission to the voting.
The process is all kicked off by the creation of a new submission wave.
To submit an entry, developers would install the Mashable Submitty extension. They then clicked 'New extension submission' in the New Wave menu, and watched a robot populate the new wave with a submission template. The robot does this by responding to the WaveletSelfAdded event, and appending text, form elements, and a gadget. The text describes the submission process, the form input elements let the developers give the robot information in a structured way, and the gadget manages the flow of submission.
The robot helps automate some of the more tedious aspects of the review process, like checking an installer is valid.
When the developer is filling in the wave, they specify the URL of the installer XML in one of the input elements. When the robot sees a URL in that field, it grabs the XML, and parses it to look for all the required fields. If there are any errors, it reports them in an inline blip, and if not, it inserts the installer element inside that blip. By doing this, the reviewers can easily install the extension from inside the wave.
The workflow gadget helps manage the sequence of steps, and let some participants move the sequence forward.
The robot automates the process of creating individual waves that are rich in content, and of creating one central table of contents wave.
After the extension is approved, the robot starts by creating an individual wave about the extension - inserting the title, description, installer, a ratings gadget, and a sharing gadget. Since gadgets don't have access to the wave content around them, the robot injects the extension name into the state of the sharing gadget so users can easily tweet about it (e.g. "Checking out Requesty- http://www..."). Next, the robot fetches the table of contents wave using the Active API and appends an image and links for the new extension.
All in all, the Submitty extension helps automate a multi-step process in Wave while still allowing for freeform discussion. In the submission waves, we would often go back and forth with the submitter when trying out the extension and start up private replies to discuss the status of the extension with just the reviewers. In the gallery waves, wave users would report bugs and request features, and on the discussion wave for the most popular extension, Mr. Ray, they even got into a passionate discussion about the future of wave.
If you're interested in running a contest in wave or employing a similar workflow for your own use, check out the code for Mashable Submitty from the samples gallery. Let us know in the forum if you have any questions.
We recently celebrated Google Wave's 1st Birthday and announced several API and protocol updates at Google I/O. Along with that we invited 17 partners and developers to showcase their Wave extensions and integrations as part of the Google Wave Developer Sandbox. We've been amazed at the many extensions and product integrations that developers have built eversince we launched Wave and we wanted to share with the public what were showcased at I/O:
To see videos of many of the above extensions in action and read more about them, check out our featured extension page. We hope these extensions and product integrations will inspire you to build more things on Google Wave. As always, we love to hear from developers. If you have feedback on our APIs or want to build extensions, read our guide and drop us a line in the Wave APIs forum. If you're interested in the Wave Protocol, check out http://www.waveprotocol.org and join the Wave Protocol discussion forum.
One of my favorite features of Wave is "saved searches." When I use a search query that I want to remember to check later, I click "save search" at the bottom of the search panel, specify a title, and then that search shows up in my nav panel as a link. When a wave matching that search query show up in the search panel, it will be labeled with the saved search terms.
I use searches for lots of things - keeping track of waves for particular Google groups (e.g. "group:email@example.com"), waves with particular tags (e.g. "tag:wavedevfaq"), waves I've contributed to ("with:me"), and oftentimes, waves created by a particular robot (e.g. "with:submitty-bot tag:status-inreview").
I always wished extensions could automatically save those searches for me, and today, I'm happy to announce that extension installers can now use the savedSearchHook to specify saved searches to be automatically added to the user's nav panel. For example, the Google I/O extension adds a saved search to make it easy to find all the conference waves, using this addition to the installer XML:
<savedSearchHook name="Google IO 2010" query="group:firstname.lastname@example.org tag:io2010"></savedSearchHook>
<savedSearchHook name="Tasky: All" query="with:me tag:task"></savedSearchHook> <savedSearchHook name="Tasky: Top-Level" query="with:me tag:task -tag:sub-task"></savedSearchHook> <savedSearchHook name="Tasky: Active" query="with:me tag:task -tag:status-completed -tag:status-canceled -tag:status-rejected"></savedSearchHook> <savedSearchHook name="Tasky: New" query="with:me tag:status-describing OR tag:status-notstarted OR tag:status-brainstorming past:1w"></savedSearchHook>
When we first launched Google Wave in developer preview mode at last year's I/O, thousands of developers started playing around on WaveSandbox.com, experimenting with the APIs, and checking out the preliminary set of specs and whitepapers on waveprotocol.org. Back then, many developers looked around and decided that they couldn't do what they wanted with the APIs yet, or the protocol wasn't fleshed out enough for their needs, so they filed their feature requests and slowly disappeared from the Wave world.
Today, we'd like to encourage all those developers to take a second look. Over the past year, and today at Google I/O, we've launched a series of improvements that make Wave a more compelling platform, product, and protocol, and enable the kind of apps and integrations developers first dreamed of when they encountered Wave.
Here's a quick recap of the last few months of API releases:
And here's what we've announced at I/O:
Beyond the API releases, we're also open sourcing a lot more of Google Wave's code, including the rich text editor, so you can learn how to run a wave server, like the one Novell Pulse is working on, and start prototyping with a simple frontend for editing and replying to waves. You can also extend that code to build your own alternative Wave clients. Today, SAP announced that they are working to adopt the Google Wave Federation Protocol in their product, StreamWork. Stay tuned for another blogpost with more pointers and details.
Now, all of this sounds great, but as a developer building on top of a platform, many of you will be most concerned about one thing: users. We've been in invite-only mode for the past year, and built up a loyal user base of about 1 million active users. Today, we will let anyone with a Google account use Google Wave (no more invites!), *and* even better, any company or organization using Google Apps can enable Wave for their domain. So, there should both be more users who want to use your extensions and more businesses that want developers to build extensions for them. Win-win!
We're not done yet, of course. The product and the APIs are in Labs, because we think it's important to stay flexible when creating a whole new paradigm in web based communication and collaboration. We want to be able to respond to your feedback, and we still have a lot left to do to make the vision a reality.
But we think we've made good progress with these improvements, and we invite you to check them out, give us your feedback, and hopefully join us on the rest of this journey.
Over the last few releases, we've been rolling out incremental improvements to the robots API, based on the feedback from all of you developers. For those of you who haven't been reading the forum waves and changelogs, here's a summary of the new features:
When you're adding new text to a blip, you often want to annotate that text with a particular set of annotations. In the past, you had to calculate the range of that text and use the annotate operation, like so:
blip.append('New text') blip.range(len(blip.text), len(blip.text)+8).annotate('style/fontWeight', 'bold')
blip.append('New Text', bundled_annotations=[('style/fontWeight', 'bold')])
For more information, read the announcement wave.
Inline Blip Positions:
Several robots produce alternate rendering of waves, like Mr. Ray and its "Wave Lite" view, and those robots needed to know the positions of inline blips inside other blips for a more accurate rendering. To help with this, we introduced a new attribute to the Blip classes to let robots access that position. For more info, see the Python or Java reference.
Read Only Roles:
A few months ago Google Wave launched the ability to have "Read-only" participants, which lets the creator of a wave set access rights for the other participants as either "full access" (the default) or "read only". We now offer that same ability in the API, so a robot that creates a wave can set the access rights of all the participants on the wave, like so:
For more information, read the announcement wave.
Check out the new features, and let us know in the forum how you're using them in your robots.
We recently introduced a new API for embedding waves, which includes a powerful new feature: anonymous, read-only access to public waves. Prior to this launch, webmasters could embed waves into their sites, but visitors could only see the content of the embedded wave if they had a Google Wave account, were logged in, and had access to that particular wave. Now, all waves with email@example.com (or a properly configured Google Group) as a participant can be embedded in a website so their content can be read by those who don't have a wave account (or simply aren't logged in).
You can view an example of this below or see it in action by visiting the KitchenSinky walkthrough documentation.
The new embed API also provides some optional parameters, like the ability to display participants in the the header panel or to include the toolbar. With an embedded wave, users are able to discuss topics in realtime and even catch up by playing back the exchange. Additionally, it provides a mechanism for staying involved in the conversation without requiring the user to constantly check the host site for updates.
If you're just interested in quickly getting a wave embedded on your site, you can simply make the wave and then get the code to paste into your site using the new Wave Element.
As you're diving in, here are a few ideas for ways to make use of embedded waves:
We hope you find this new API and this new level of access useful, and we have more improvements to the embed API on the way. For example, at the moment, embedded waves do not work in Internet Explorer (even with Google Chrome Frame), but we will be resolving that issue.
We look forward to seeing what you come up with. If you have questions or comments, please discuss in the forum.
We launched the new Robots API (v2) last month, and since then, we've seen a a slew of new and interesting robots from Google Wave developers -- proving that robots can now be used in more ways than ever before.
We want to share some examples here, to give you a taste of the possibilities:
We've added 10 new articles to the documentation, written by both the Google Wave API team and developers like you, and we hope these articles will give you a new way of understanding how to use the APIs.
After launching the new robots API a month ago, robot developers have already written a bunch of articles about using it in various ways, from developing in Eclipse to integrating with Salesforce:
Meanwhile, gadget developers have been spreading their knowledge on writing gadgets, with articles on everything from Flex to GWT:
If you wrote an article yourself, please share it in the forum. Happy reading!
Posted by Pamela Fox, Developer Relations
When we shipped the FedOne code to demonstrate the Google Wave Federation Protocol, we included some overview information and basic documentation on how to get it up and running. Since then, the community has stepped up and contributed some great documentation, and we wanted to highlight a couple of great resources that may be helpful to anyone interested in the Google Wave Federationn Protocol.
For example, Anthony Watkins wrote several articles to explain the architecture of the FedOne code:
In an effort to bring together this and other community-created resources in a single place, we've gathered links to Anthony's articles, along with links to articles by James Purser and Bryce into a wiki page. Be sure to check them out, and let us know if we've missed any great articles on the Google Wave Federation Protocol or the FedOne code. Share your links on the wave protocol discussion forum and we will update the wiki as they come in.
Also be sure to check out the new, recently open sourced wave document model code, as announced by J.D. in the Google Wave Protocol Forum:
We have just open sourced a significant new chunk of Google Wave source code: the wave document model. The new code, some thirty-eight thousand lines of code mainly in the org.waveprocotol.wave.model.document package, implements useful and efficient data structures for reading and manipulating wave documents. This is the same document model used by the Google Wave client and servers.
In case you missed it, Novell Pulse recently demonstrated federation with Google Wave.
Finally, be sure to visit us if you are attending Google I/O, there are some some great talks lined up, we hope to see you there!
Posted by Joe Gregorio, Developer Relations
"Tell the chef, the beer is on me."
"Basically the price of a night on the town!"
"I'd love to help kickstart continued development! And 0 EUR/month really does make fiscal sense too... maybe I'll even get a shirt?" (there will be limited edition shirts for two and other goodies for each supporter as soon as we sold the 200)