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 email to google-wave-...@googlegroups.com. >> >> > > To unsubscribe from this group, send email to >> >> > > google-wave-api+unsubscr...@googlegroups.com<google-wave-api%2Bunsubscribe@ >> >> > > 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 >> > athttp://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=. > > > -- 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=.
