@qMax: As of today, it appears to delete only the blip and its inline replies (the collapseable blips) - not standard reply children.
@shitu: Last night I was testing deleting of all blips on WAVELET_SELF_ADDED. It worked fine then, I recursively went through the children and all were deleted - it also gave me every blips text content. (I did not test inline replies...) However, sometimes .delete() will throw an exception in the logs - but that issue has been raised on the wave API issue tracker. There still seems some confusion about the model used by Wave when it comes to what blips are given with an event. It's also a moving target as bugs get fixed. In the documentation and guides I've used for the 'capabilities.xml' file there is an extra attribute which tells the wave server which blips content to send on that event to the robot. This attribute can be set to at least four values (sadly, I can't find the blog page which gave the list), but the main two are: - parent - children Here's a nice example capabilities.xml: http://code.google.com/p/google-wave-resources/source/browse/trunk/samples/extensions/robots/java/tweety/war/_wave/capabilities.xml?spec=svn21&r=21 To ensure your get the children for an event, specify context="children" as well as content="true" (to get their content) for your event. Like so: <w:capability name="blip_submitted" content="true" context="children" / > If you want the parent above of the event's blip, specify context="parent" as well as content="true" (to get the parent's content) for your event. Like so: <w:capability name="blip_submitted" content="true" context="parent" /> You always get the content of the event blip I believe - though I could be wrong if you set content="false" - never tried that. The context attribute is also mentioned in passing under the Java API method blip.getChild(int index), getChildren(), etc... methods here: http://wave-robot-java-client.googlecode.com/svn/trunk/doc/com/google/wave/api/Blip.html "Returns the Nth child blip of this blip (if available). Use the isChildAvailable() method to check for availability of the child blip. Note: The behavior of this method is dependent on the 'context' settings in the Capabilities XML configuration. Child blips may not have been sent with this event." Hope that clears up some of the misunderstanding on how you choose what data to be sent for an event and what is possible currently. If you have a sandbox account I recommend you do a search for: with:public tag:Office Hours There's a lot of answers there from Google on various topics not covered in the main tutorials - though some of it is out-of-date now since the API development is moving forward. On Nov 23, 3:22 am, Vikram Dhillon <dhillon...@gmail.com> wrote: > The visual really helped, I wasn't thinking properly so I apologize for that > and thanks for your clarification on the subject. So from what I understand > now, how about this: if we can export the whole conversation, to a file or > something, then the robot can stri[p off everything besides the root blip and > then sync it back may be > > -- > Regards, > Vikram Dhillon > > On Sunday 22 November 2009 08:15:13 pm Olreich wrote: > > > > > GetChildren on the root blip will get the first blip. Unfortunately, > > because the root blip has to be the blip submitted to have that > > function work, it's limited. In fact, it's even more limited because > > of the fact that the root blips child's child is null in the current > > version of the API. (an annoying quirk) > > > Visual: > > > r--->Blip 1 > > ^--->Blip 2 > > ^--->Blip A > > ^--->Blip B > > ^--->Blip C > > ^--->Blip 3 > > ^--->Blip 4 > > r = root > > ^ = child of last indentation (Blips A and 3 are both children of Blip > > 2) > > > So in that context, let's say the Event happened on Blip 1. Well, it's > > the root blip, so it has no parents, but it does have a child (Blip > > 2). getChildren will return a list with Blip 2 in it. But, if one > > get's Blip 2 (in any fashion) because it is not the Blip that was > > acted upon, you will get null for both it's parent (Blip 1) and it's > > children (Blips A and 3). > > > The reason for this is that a bot works in the same way that a human > > participant does, in that every update has just the information about > > the one blip, instead of all the blips, to reduce bandwidth. > > > Something that just came to me would be, upon the bot being added, it > > should have to be able to see ALL the blips (like when you get a new > > wave and having the entire conversation load, but only having small > > parts change after that). Thus, it should be able to make a full list > > of the blips. Then, when a blip event happens, and the blip is not on > > the list you made, then the Bot adds it to the list. I'm not sure if > > this is the functionality, but it should be. And if it's not when I > > test it, I'll be adding a bug, because the Robot is not a full > > participant unless it is able to read the entire conversation right > > off the bat. > > > -- > > > 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=en.
