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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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)" <[email protected]> >> >> >> 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 <[email protected]> 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: [email protected]) >> >> >> > > 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 <[email protected]> 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 <[email protected]> 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-wave-api?hl=.
