I'll admit I haven't been able to read through this whole wave yet, but I wanted to let you know that we are working on the ability for robots to create Waves on their own (outside of an event response). It will involve registering your robot using Oauth to authenticate it to the Wave server.
This capability will make it easier for a robot to update a Wave when it has relevant information, or on a normal App Engine cron job. We mentioned this at several recent developer events, but have not published the slides from those yet. - pamela On Tue, Nov 17, 2009 at 12:53 PM, Adam Ness <adam.n...@gmail.com> wrote: > I think you missed the point that I was making... There is no JSON RPC > endpoint on the wave.google.com system that is accessible to the > robots. wave.google.com is an RPC "client" as far as the robot is > concerned, and (based on the API that's currently available) cannot > initiate requests to the server to create waves, blips, or anything > like that. It's only conduit to cause the server to do something is > in response to a request from Wave.google.com. The way that it > creates blips on the server is by sending a command back through the > response which tells the server to create a blip, but again, this > response is part of the same HTTP stream that notified the robot of > the event. > > If you're receiving outside events in your robot, then it cannot > respond to wave.google.com with changes, because the request didn't > come from wave.google.com, it came from your external event source. > It could queue up responses that should happen, and send them along to > wave.google.com the next time wave.google.com makes a request, but > there are simpler and more elegant ways of solving that problem (such > as implementing your own federation server, which can modify waves in > it's posession all it wants, and add participants on any of the > servers it's federated to as recipients. > > On Tue, Nov 17, 2009 at 12:19 PM, Olreich <olre...@gmail.com> wrote: > > If we can't push new data to waves, then we can't delete or create new > > blips. The thing is, we're currently stuck in an event loop that the > > server makes fire upon events. But, if one were to send a JSON RPC > > message to the server, the server should just fire it and not really > > care if it's in response to a event, or if the robot is just doing it > > because it wants to. (obviously there is authentication). The only > > problem with this is that the robot is a new instance in every wave, > > though one instance should be able to play with another instance's > > wave if they were to share wavelet objects via the datastore or > > something. > > > > On Nov 17, 2:54 pm, Adam Ness <adam.n...@gmail.com> wrote: > >> Digging in to the Java API, it looks like the way a robot lifecycle > >> goes is this: > >> > >> 1) A change to a wave in which the robot is a participant occurs (one > >> of the several events). The wave server initiates an HTTP request to > >> the robot servlet endpoint. > >> 2) The servlet recieves the event notification and deserializes it > >> into some objects > >> 3) The servlet performs some processing on those objects, and > >> generates some change objects which it attaches to the event object > >> 4) The changes object is serialized into JSON, and that JSON is sent > >> as the response to the HTTP request from step 1. > >> 4) The wave server implements those changes into the Wave > >> > >> It appears that all communications with the Wave Server comes through > >> these requests and responses, so there's no way to "push" data to > >> google's wave federation server outside of as a response to an > >> incoming event. Perhaps the python api works differently, though I > >> don't understand python well enough to dig through the code and verify > >> that. > >> > >> To push new data to the wave server would require a fundamental change > >> to the way that Robots operate. I think that if this is the kind of > >> functionality you're looking for, you might be better off implementing > >> a custom federation server, which can serve up its own messages. I'd > >> need to dig into that protocol to know for certain though, but my > >> basic conception of how such an architecture could work: > >> > >> 1) External event triggers a wave created on your custom federated > server > >> 2) The federated server creates a wave, and adds you as a participant > >> on the wave. > >> 3) You being added as a participant causes your server to establish an > >> XMPP connection to wave.google.com and notify it of the existence of > >> the wave > >> 4) wave.google.com and your federated server continue to exchange > >> change notifications as they keep the wave in sync > >> 5) The wave appears in your wave.google.com inbox > >> > >> Of course, wave.google.com could be substituted with any server which > >> provides mailboxes (waveboxes?) for users. > >> > >> > >> > >> On Tue, Nov 17, 2009 at 11:12 AM, Olreich <olre...@gmail.com> wrote: > >> > That is true, the only way to get the Robot to access waves would be > >> > to have it added and to have all of the Wavelets saved using a > >> > persistence method (so that you can re-deploy without losing all > >> > access to them). This would give you access to all of the waves that > >> > the robot is added to > >> > >> > Though with the Parent/Child relationships being so wonky right now, > >> > one still doesn't have the ability to walk around the blip tree with > >> > any sufficient ability. Bugs have been filed for all of the Parent/ > >> > Child relationship stuff, so that's part of the wait. > >> > >> > As for Adam's solution, it looks much cleaner than mine, though I'm > >> > not sure how instantaneous that would be. > >> > >> > On Nov 17, 1:59 pm, Adam Ness <adam.n...@gmail.com> wrote: > >> >> Another way to pipe information into the robot would be using REST > >> >> calls, since the robot is actually sitting at an HTTP endpoint on the > >> >> appspot servers. This would be significantly easier than opening up > a > >> >> TCP Socket. Alternately, you could set up another servlet on the > >> >> appspot server that put instructions into the appspot datastore, and > >> >> had the Robot respond to them (potentially using polling with your > >> >> "wait") solution. > >> > >> >> I don't believe that a robot in this context would have access to any > >> >> waves though, since it wouldn't have a "context" to execute against. > >> > >> >> Adam Ness > >> > >> >> On Tue, Nov 17, 2009 at 10:51 AM, Olreich <olre...@gmail.com> wrote: > >> >> > The API calls that we listed are indeed for creating new waves, not > >> >> > wavelets, as this does not allow for those inline "private reply" > type > >> >> > wavelets that users can create (which there is still no > functionality > >> >> > in the API to do). Robot's are indeed meant to respond to events, > and > >> >> > have no ability to create unique handlers or randomly push data > down > >> >> > to the servers without a time-based loop that runs continuously and > >> >> > adds tons of CPU time to the robot, which may be thwarted with the > >> >> > "wait(ms)" function available to Java Robots at least. > >> > >> >> > As for the idea that one can push data from an external data source > to > >> >> > a robot, this may be able to function with Sockets, with a robot > being > >> >> > one end of the socket, and your external service being the other. > To > >> >> > make it create waves and such, you may be able to merely add the > >> >> > Google Wave Robot API to the project and somehow get your hands on > a > >> >> > wavelet, such as with the wasSelfAdded()[java] event. That would > also > >> >> > be the time to spawn an open server connection. Then, if the > external > >> >> > program has something to tell the Robot, it sends it over that > >> >> > connection. Setting up the connection might be tricky, as I would > >> >> > guess robot instances are not the easiest to find (so you'd > probably > >> >> > connect to the static site, save the robot address and then create > the > >> >> > reverse relationship). And, this all depends on how much freedom > >> >> > Google AppEngine and Google Wave has given for networking. > >> > >> >> > Pushing requests to Wave is dangerous, as there would be no > >> >> > authentication. I can see Google having this be fleshed out once > they > >> >> > allow all Robots to participate, rather than just AppSpot Robots, > but > >> >> > for now, it's not safe, so they probably won't allow it until they > >> >> > figure out how to make it safe. After all, Robot's have quite a bit > of > >> >> > power to annoy everyone, so long as they are initialized by a > single > >> >> > user adding them to any Wave. They can also ruin waves, lock waves, > >> >> > and do all sorts of annoying things when put into a Wave that they > >> >> > shouldn't be. > >> > >> >> > On Nov 17, 8:55 am, jhouk <jsh...@gmail.com> wrote: > >> >> >> Thanks Olrech and Pamela! > >> > >> >> >> Please forgive me if I'm being dense here, but it looks like the > APIs > >> >> >> you're listing are designed for creating wavelets within an > existing > >> >> >> wave, or spawning a new wave from an existing wave. The issue > being > >> >> >> that robots are--and please correct me if I'm wrong--designed to > >> >> >> listen in on an existing wave and react to activity within the > wave. > >> >> >> What we're looking to do, on the other hand, is run services > external > >> >> >> to Wave, and based on external events, communicate to Google Wave > that > >> >> >> a new top level wave (not wavelet) needs to be created with a set > of > >> >> >> participants. > >> > >> >> >> Now, as I type this I'm thinking that I might be able to use the > >> >> >> current APIs in an unorthodox way to get this functionality. > Perhaps > >> >> >> I can manually create a starter wave with myself and a monitor > robot > >> >> >> as participants to bootstrap the robot. Once it's running, the > bot > >> >> >> can 'pull' any new wave notifications from our external service > and > >> >> >> spawn new waves with the appropriate participants. > >> > >> >> >> Still, it seems like some kind of Google Wave listening service > that > >> >> >> would allow us to 'push' requests to Wave would be a more > >> >> >> straightforward and efficient mechanism, but this should be enough > to > >> >> >> get us started. > >> > >> >> >> Thanks again! > >> >> >> --Justin > >> > >> >> >> On Nov 17, 5:24 am, "pamela (Google Employee)" < > pamela...@gmail.com> > >> >> >> wrote: > >> > >> >> >> > In addition, I published some sample code here for Python wave > creation:http://wave-samples-gallery.appspot.com/about_app?app_id=60017 > >> > >> >> >> > <http://wave-samples-gallery.appspot.com/about_app?app_id=60017>- > pamela > >> > >> >> >> > On Mon, Nov 16, 2009 at 1:48 PM, Olreich <olre...@gmail.com> > wrote: > >> >> >> > > To create a wave via programming in Java: > >> > >> >> >> > > wavelet.createWavelet(participants, dataDocument); > >> > >> >> >> > > wavelet -> A Wavelet object. > >> >> >> > > participants -> A List<String> of the participants that you > want to > >> >> >> > > include (format of name: usern...@googlewave.com) > >> >> >> > > dataDocument -> A String referring to a named dataDocument > where the > >> >> >> > > waveId that is created will reside (for callback utility). (I > may be > >> >> >> > > wrong on this one, as I've not used it) > >> > >> >> >> > > Check the Java Docs for more information. > >> > >> >> >> > > > http://wave-robot-java-client.googlecode.com/svn/trunk/doc/com/google... > >> >> >> > > , > >> >> >> > > java.lang.String) > >> > >> >> >> > > To create a wave via programming in Python: > >> > >> >> >> > > robot_abstract.NewWave(context, participants) > >> > >> >> >> > > robot_abstract -> An instance of the robot_abstract class > >> >> >> > > context -> An instance of the context class > >> >> >> > > participants -> A list of participants > >> > >> >> >> > > I'm not very good with python, so that's not very informative > I don't > >> >> >> > > think, but that's the function. > >> > >> >> >> > > > http://wave-robot-python-client.googlecode.com/svn/trunk/pydocs/wavea... > >> > >> >> >> > > On Nov 15, 10:30 pm, jhouk <jsh...@gmail.com> wrote: > >> >> >> > > > Hi all, > >> > >> >> >> > > > We have this exact same question. We'd like to use Wave as > the chat > >> >> >> > > > mechanism in a tool that we're building, but for it to work, > we'll > >> >> >> > > > need the ability to programmatically create a new wave, add > >> >> >> > > > participants to it, and fetch its wave ID so that we can > embed it in > >> >> >> > > > our tool. Any chance of that kind of functionality coming > down the > >> >> >> > > > pipe? > >> > >> >> >> > > > In short, *bump* > >> > >> >> >> > > > Thanks! > >> >> >> > > > --Justin > >> > >> >> >> > > > On Nov 12, 9:14 am, drone <andr...@gmail.com> wrote: > >> > >> >> >> > > > > Hello, > >> >> >> > > > > I see, currently Embed API exposes Google Wave client's > Wave panel > >> >> >> > > > > functionality. > >> > >> >> >> > > > > So I'm wondering, are there any plans to expose more > functionality, > >> >> >> > > > > which would allow to embed Wave List (Search) panel, > create newWaves > >> >> >> > > > > programmatically, etc? > >> > >> >> >> > > -- > >> > >> >> >> > > You received this message because you are subscribed to the > Google Groups > >> >> >> > > "Google Wave API" group. > >> >> >> > > To post to this group, send... > >> > >> read more ยป > > > > -- > > > > You received this message because you are subscribed to the Google Groups > "Google Wave API" group. > > To post to this group, send email to google-wave-...@googlegroups.com. > > To unsubscribe from this group, send email to > google-wave-api+unsubscr...@googlegroups.com<google-wave-api%2bunsubscr...@googlegroups.com> > . > > For more options, visit this group at > http://groups.google.com/group/google-wave-api?hl=. > > > > > > > > -- > > You received this message because you are subscribed to the Google Groups > "Google Wave API" group. > To post to this group, send email to google-wave-...@googlegroups.com. > To unsubscribe from this group, send email to > google-wave-api+unsubscr...@googlegroups.com<google-wave-api%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/google-wave-api?hl=. > > > -- You received this message because you are subscribed to the Google Groups "Google Wave API" group. To post to this group, send email to google-wave-...@googlegroups.com. To unsubscribe from this group, send email to google-wave-api+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-wave-api?hl=.
