Tip:
Highlight text to annotate it
X
>> Today, I want to talk about Google Wave Robots and in particular, the new Robots API
version 2 and some of the features that it has for robots to take advantage of. So, to
start with, robots are basically superhuman participants in a Wave, that it can sit on
a Wave and listen to everything that's happening in that Wave and they can respond by doing
anything on that Wave like editing a text, or adding replies. And they can even do stuff
like creating new Waves just like a human can. However, robots are programmatic and
so as a developer, you need to understand how to actually program these robots in order
to listen to the events that you want them to hear in order to respond the way that you
want them to respond. All right, so, to start off, let's actually look at an example robot,
and we'll start by looking at what it looks like to the user of the robot, all right.
So, in this example, we are writing a little diary entry about an incredibly emotional
day with ups and downs, and we've got some little ASCII codes for smiley phrases and
frowns, and the whole that. So, we write this up and then we add the skimmy robot onto the
Wave. So, the skimmy robot is basically an emoticon robot. It goes to the Wave and finds
places that it can replace with emoticons. So, after we add skimmy, then we see that
our smiley face has become a smiley, our frowny face is becoming incredibly sad and our heart
is a beating red heart. So, this is what it looks like to the user, now, I want to look
and see what it looks like behind the scenes. So, we go back to the one when we create this
Wave, and we add the robot. Then the Wave server sees that a robot has been onto the
Wave and the Wave server says, oh, well, I need to let this robot know that it's been
added and I need to give it some information about this event. So the Wave server actually
constructs a JSON which describes the events and the context that it happened in. So in
this case, the event is a wavelet self added and the context is the wavelet that it happened
in, so the context will describe the title and the text in that that blip and information
like the participants, right? So it constructs this JSON and then it sends the JSON to the
robot. Now, every robot currently runs on App Engine and every robot has a particular
endpoint that the Wave communicates with, so it's _waves/robot/jsonrpc. So the Wave
server will send the JSON to that endpoint and then the robot will process the JSON and
it will respond with its own JSON, and its own JSON would describe operations that it
wants to perform on the Wave. So, in this example, the operations are replacements,
or it's going to replace the smiley faces with images and the frowns with images and
all of that. So it sends the JSON of operations to the Wave server, and the Wave server sends
those operations to the Wave client. And now the Wave Client shows our lovely animated
GIFs, so this is basically how a robot works. It's an application that accepts JSON-RPCs
and sends them back out in itself in order to communicate with Wave. Now, you, as a developer,
probably don't want to spend your time, you know, de-serializing JSON and serializing
JSON, right? So what we do is that we provide APIs in the two main App Engine images like
on a Java, and we let you use those APIs in order to process events and to respond to
events. All right. So, here's the example code for the skimmy robot that I've showed
and this is in the Python API. So we start off by constructing the robot and passing
in some profile information for the robot and by registering a few event handlers. So,
here, we're registering for the blips submitted and the wavelet self added event handlers.
Then, we define a function that responds to these events and that function receives the
event information and the wavelet contacts and it can use that information. So, in this
case, it iterates through the blip to see if there's any possible emoticons in it, and
if it finds then, it construction operation to replace the text in an image. So it's basically
just constructing a replaced operation on the blip. And, basically, this code is in
fact de-serializing JSON, turn it into Python objects and then taking the Python operations
and serializing those into JSON operations. It's just a much nicer way of creating this
JSON-RPC communication with the Wave server. So that is basically a robot. It's a very
typical robot and we showed it in Python but in Java, it would be similar. And as you can
see, robots are pretty much all about events in operations. So now I want to focus on various
features of the events and operations aspects. So, starting with events, the whole point
of events is to let developers subscribe to only in the events that they care about and
not have to worry about events that they don't care about, right? And, this is because your
robot is actually a webapp, and you don't want your webapp to be hit if it's not necessary,
right, if there's nothing for it to process. You only want your webapp to be contacted
if there's actually something that your webapp wants to process, right. So what we're trying
to do is provide enough events so that you can, you can subscribe to the ones you care
about and ignore the ones you don't care about. So here's a list of the events that we have
currently. There's stuff like title changed, participants changed, blip created, form button
clicked, gadget changed, et cetera. There is--our most frequency, high frequency event
called document changed which is something like, you know, every four characters that
they type, you'll get an event, so this really range in their frequency. But, these are the
events we offer now and we may offer more events in the future as developers express
that there is something else, some level of granularity that they need, but you can do
an awful lot of the current events here. All right, now, we said earlier that when a robot
sends events or receives event information, it also receives context information and the
context describes the wavelet that that event occurred in. Now, in the API, we have this
notion of you being able to specify your own context and for there being a default context.
So the reason for this is because some waves can be really, really big and there are some
developers that want to know about that entire wave and all of that information. And there
are other developers that really only care about one blip in that wave. So we want to
make sure that if you're a developer that cares about the entire wavelet, you can get
all of that. But if you're a developer that only cares about a little bit, then you're
not going to worry that your robot is going to get hit up with this, you know, a massive
amount of information every time there's an event. So, we have a default context and then
we let you override that default context depending on your particular needs. So, for example,
looking at this wave here, there is a blip in the middle that we're editing, that's the
one left in green, and then there's several blips around there and then there's a parent
blip; so the default context is root, self, parent and children. So in this case, it would
be the selective blip, it would be the root blip--the one with the title--and there would
be a parent--the one right above it--and there will be no children. So the default context
here would give you a JSON describing three blips of information. Now, you can override
that context to specify anyone of these context options or any combination of them, all right.
So, if you're a robot that only cares about the current blip, you might override it to
say, you only want self. If you're the one that cares about the entire blip like your
robot that exports a blip to PDF, then you would specify all so you'll get all of the
information. And the way to do that is simply when you register an event handler, you specify
the context as one of this constant or a combination of the constant, and then the Wave server
will know to only sense the specified amount of context to your robot. Okay, so, we also
have a notion of event filters. Now, there are a lot of robots that like to actually
respond to particular things inside a Wave, right, and process those things that it finds.
They're basically looking for matches and processing those matches. So, ideally, those
robots would respond in real time, meaning, those robots would be listening to the document
change event, and as soon as they saw something that they match, they would go ahead and process
that match. Now, if the robots are listening to document changed then they are potentially
getting a whole lot of events and it's possible that they're going to get a lot of events
that have nothing for them to process, all right. So what we let you do is actually set
a filter on the event to say that you only care about the event if the event text actually
matches a certain regular expression. So, looking at this example here, this is intended
for a robot that converts rapid text into Wikipedia links, right. So the robot wants
to respond immediately on document changed and convert those immediately. But it only
wants to be notified of the document changed events if there's actually rapid text for
it to respond to. So, all you have to do here is when you register an event handler, we
will also specify a filter and the filter is just a standard rejects that says what
the text should match for your robot to actually care about it. And then your robot will only
get that event when the filter matches, and then presto, it can do all of its replacements
in real time. So the event filter is a nice way of having a robot that responds in real
time but isn't constantly notified to events that it doesn't care about. Right now, you
can mostly use the event filter on the document changed event and a few other events like
gadget changed and allocation changed, and we'll probably continue to add the filter
to other events as it becomes desired. Okay. So now, we have operations, and it's basically
the robot doing stuff. So, the goal of operations is to let your robot do as much as a human
can, right, so basically do everything inside a Wave. So here's a list of current operations
that we support. There is stuff like replying, adding and removing tags, adding participants,
inserting inline blips, appending html; these are all, you know, really useful for modifying
an existing wave. We also have an operation Create Wavelet which will create a new Wave
and Fetch Wave which will fetch a wave that the robot is on. Let's do the operations that
we added in the recent API. Now when you're doing the document modify operations, there
is a lot of elements that you can insert into a Wave and here is the list of the elements.
There's a lot of form elements you can insert. You can also insert lines which lets you get
bullets and headings. And also insert gadgets and so as images. There's a lot you can do
with gadget robot interaction, so that's pretty, that's pretty crucial to look into to. Okay.
Now, this is probably the most exciting part of our new API and that's what we call the
active API. So, in the past, in the old API, robots could only do operations in response
to events and this is kind of the way I've also presented robot so far. But in fact in
the new API, robots can do operations at any time, so this means that you can do stuff
like have your robot create Waves from another webpage and do stuff like have your robots
perform operations from a Chrome job which really opens up a whole new range of robots
that can be created. And also it makes it much easier to integrate with third party
systems because you can have your robot respond to events on the third party system or have
your robot respond to actually, you know, Web forms on that third party app. So the
way we do this is we just have that you register your robot and we basically give it a OAK
consumer key and consumer secret and you put that key in secret into your code, and once
you've done that that means that you're now able to do operations at any time and we authenticate
you every time you do those operations to make sure that you're all validated. So this
means doing stuff like creating a new wave from a form and means stuff like fetching
a Wave at any time and doing operations to it. There's a lot of possibilities once you
start making active robots and this is one of the really exciting things in the new API.
And, along with that, we've introduced the notion of Proxying-For. So this is another
thing that's really crucial for integration with their price systems because the thing
is that third party systems usually have their own notion of users and you often want to
represent contributions from users on the third-party systems inside of Wave, right,
and represent it visually so that it make sense. For example, we might have a Twitter
robot. The Twitter robot updates the Wave with replies that represent tweets from Twitter
users, all right. So, here is tweets from Douwe's Twitter account, all right. And as
you can see the Avatar and the name, that's all actually the Avatar that Douwe uses on
Twitter. This is all pulled from the Twitter system and this is nice because somebody who's
used to seeing their tweets on Twitter and now sees them in Wave, sees them looking very
much the same. So they think, oh, yes, this is the same user, I know who this user is.
Even though Douwe and Twitter isn't really a Wave user; he's a Twitter user. And, what's
actually happening is that these operations are all done by the robot. They're just done
by the robot on behalf of a user and this is done using a plus syntax in the robot address
that represents that user and then there's a profile that's pulled for whatever is after
the plus. So it's good because it means that you can make Waves look like they're contributed
from those users, but you can always prove that they came from the robot, so that's good
for having some credibility. Now the way to do this in the code is for every operation
you can simply propend the Proxying-For method and that tells the API that you want to do
an operation on behalf of a user, so here we're going to do reply on behalf of Douwe.
Now, in order to let them know what profile information to serve for operations from that
user, you just create a profile handler and that profile handler gets passed a username,
and for each username, you respond with their profile information; their name, their image,
their profile hereon. So it's really probably simple but, with that combination and stuff,
you can really represent users from third-party systems much better. All right, so, that is
basically the new Wave Robots API version 2, and hopefully, you check it out and make
your own robot and let us know how it goes in the forum.