I think I recall that Bouncy doesn't respond to posts made by robots (It can be added by robots though).
I would like to think the solution would be to have blip content regex matching in compatibilities.xml On Dec 4, 9:54 am, Daniel Faust <[email protected]> wrote: > > I tried adding code to call Bouncy in to assist my robot in escape :D > > Sadly, it came to the wave at my robot's call, but didn't respond > > to the robot's cry of distress! > > Sounds like a good idea. If i'm guessing correctly, bouncy needs to be > added to the wave and then receive configuration messages via messages > posted to the wave, right? In that case, posting that extra message to > configure bouncy to drop the bot out of the wave seems like an > expensive operation. > > Imagine the situation if bouncy could be added to a wave, and then, > via a cheap and direct urlopen() call from the bot to bouncy, be > configured behind the scenes to remove the bot from the wave. Could > that be possible? The only issue I see here is that that urlopen call > won't hand over bouncy any context which it will probably need to > remove the bot from the wave. On the other hand, bouncy could queue up > the request removal and execute it during the next incoming message > coming from the problematic wave. > > one issue is that if bouncy is also receiving all that incoming data, > then it might be the case that it also hits the quota limit, which > might be the reason why bouncy didn't respond to your call. So maybe > having google remove the incoming bandwith quota limit on bouncy would > be an good thing to do. Or, if that won't happen, built a network of > bouncies, which take care of each other so that no more than one is in > a given wave, and where, if one dies, others could jump in. or the > affected bot would first query the system to see which bouncy bot is > still up and running. > > There would also be the need of taking protective measures against > direct urlopen() configuration requests from sources which might have > bad intentions. > > Probably doing something with the capabilities.xml would be a better > option. Or add a dynamic blacklist.xml file. > > ---------- > > The issue with gadgets requiring user interaction before being allowed > to submit data seems to be a good thing to desire. Because, as it > looks now, it's only necessary for someone to take a look at a wave, > and, as soon as a gadget gets loaded and submits data, the user gets > inserted as a participant. At least it looks that way, since some > waves have a large amount of participants whose inclusion couldn't be > explained by other means. -- 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=en.
