Yeah, I think I found that too, antimatter15 - since Bouncy worked for my human account at the time I tried it on the same wave I was testing my robot on.
The blip content regex solution won't help robots that don't remove the triggering text content: e.g. text management robots, notifying, etc. But I have thought of another idea, have a whitelist of gadgets that the robot specifies it wants to listen to in the capabilities.xml. Are there any situations when a robot would want to listen to unknown gadgets? The white-list (rather than black-list) would then allow a similar method to the regex content filtering on what gadgets get their events sent to your robot. This could either be a list of gadget URL's or just a single regex for the gadget URL's to match against before sending the gadget events to the robot. On Dec 4, 8:06 pm, antimatter15 <[email protected]> wrote: > 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.
