I agree, a gadget open in all viewers' browsers can submit a state change on a short Javascript timer event leading to a horrendous amount of potential events.
Even worse if you consider malicious possibilities, like having a robot insert one of these small gadgets in every blip in a wave. Upon one user opening that one wave to read it, all robots will receive an extended spike in BLIP_SUBMITTED, even worse if said user(s) leave the wave open in a separate tab for days on end. Pamela has said on the API issues that she believes that the new API's GADGET_STATE_CHANGED will still cause a BLIP_SUBMITTED - so sadly, it's not separating it from triggering other non-gadget change events. I can understand that if they stopped the BLIP_SUBMITTED event on a GADGET_STATE_CHANGED it would break most current robots checking for a gadget change through BLIP_SUBMITTED. This issue that requests a new TEXT_STATE_CHANGED event might be worth starring so that robots can get a separate event from gadgets for text only changes. I noticed they've added one for ANNOTATED_TEXT_CHANGED in the new API, so this would complete the set and allow any robot to process all events separately. http://code.google.com/p/google-wave-resources/issues/detail?id=552&can=4&colspec=Stars%20ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary%20Internal For those curious about the new API, more info here: http://code.google.com/apis/wave/extensions/robots/protocol.html On Dec 2, 5:40 am, Olreich <[email protected]> wrote: > I think I figured out the issue. For every person, the blip submitted > event is happening, and the Robot is receiving many more than 1 > request per second. It's receiving however many people there are > watching the wave requests. The problem is that there is no way for > the gadget itself to update independently of the users, and thus, each > user must submit an update request for themselves, rather than the > gadget updating every second with a list of users who have the gadget > running. > > There is also no ability for the gadget to tell if a user stops > looking at them, compounding the issues stated above. The only way for > a gadget such as this to operate is to inundate the users (and Robots) > with requests (2.6k requests with 2 people over the course of a few > minutes). This is just unacceptable with the quotas for Robots set as > they are. The massive amount of data being passed around used 2% of my > "quota" in just 20 minutes. Assuming much larger scales, this sort of > architecture would never hold up. Gadgets cannot be mini-applications > unless they have the ability to reduce the load to something more in > the order of 1 request per second maximum. This reduces the bot's > load, but only by half, and it needs to be mitigated more. This can be > done via creating a new event for gadgets, so that Robots can ignore > them if there's serious issues with bandwidth usage. > > Oftentimes Robots will not care about gadgets anyways, so having an > opt-in solution would be quite manageable. This is especially useful > for Robots that are solely gadget-extenders, meant to increase the > productivity and awesomeness of a gadget, in that they can ignore all > users blip-submitting and just care about when the gadget updates the > wave's state. > > There are probably better solutions too, but there is a preliminary > one for consideration that hopefully gets the idea across. > > On Dec 1, 11:21 pm, Olreich <[email protected]> wrote: > > > It doesn't seem like that gadget should be causing an onblipsubmitted > > every second... > > > On Dec 1, 9:41 pm, Stephen George <[email protected]> wrote: > > > > Daniel, I agree that it's difficult to remove a robot from a wave of > > > over 200 participants. > > > > I like to use [email protected] in that situation to avoid > > > having to sift through the list. Glad that you were able to resolve > > > it and save your exhausted bot. > > > > On Dec 1, 5:44 am, Daniel Faust <[email protected]> wrote: > > > > > I'm in a ugly situation. > > > > > Due to a 3rd party gadget in a wave which has my robot as a > > > > participant, the bot is depleting it's Incoming Bandwidth quota after > > > > only 4 hours. > > > > > That gadget -- judging from the bot's logs > > > > it'shttp://www.razorcam.com/seconds_spent_by_everyone_reading.xml-- > > > > causes an OnBlipSubmitted every second. > > > > > This means that every second the entire context is being pushed into > > > > the robot. > > > > > I tried looking at the participant list in the wave through the normal > > > > wave client, but the list is huge (1000+), and there is no way to > > > > scroll through it, so that I can't find my bot to remove it from > > > > there. (Ok, fixed that, got a computer with a bigger screen and used > > > > the ctrl- to make the page smaller) > > > > > I've seen a removeSelf or something similar in the API which allows a > > > > bot to remove itself from a wave, but at that time, about a month ago, > > > > it was not implemented. > > > > > Maybe there should be a place where we can submit robots/gadgets that > > > > should be blacklisted due to unfair behaviour, and maybe the docs > > > > should mention the side effects of implementing a highly active > > > > extension. > > > > > Or maybe an extra element in the capabilities.xml file which defines > > > > which waves, or submissions from certain robots or gadgets should be > > > > excluded from being processed. > > > > > I truely doubt that razorcam.com had bad intentions, so I'm not angry > > > > at all. > > -- 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.
