Good to know it looks like you can combine the context values. Though with WAVELET_SELF_ADDED there would not be a parent - since the root-node is returned with that event - it is the top-most blip and has no parent logically...though I've not checked to see if it's null or points to itself, I would expect null there.
I don't know if you've tested my robot cleantxt on WAVELET_SELF_ADDED yet as I offered in another thread - it proves it's possible. Another quick test on it on a new wave there and the functionality remains tonight. Perhaps if you show your recursive code we might spot a difference? However, during my testing tonight I was trying the BLIP_SUBMITTED event and with that one I can't get the submitted blip's children, not even their Id's - it always returns 0 children, same for DOCUMENT_CHANGED. On Nov 26, 3:50 am, Stephen George <[email protected]> wrote: > Olreich, > > I'll start by saying that I haven't had much success with getting > both. > > However, if you take a look at Google's implementation of the private > method AbstractRobot.processCapabilities(), it looks like it *should* > be possible by splitting the contexts with commas: > > <w:capability name="WAVELET_SELF_ADDED" > context="PARENT,SIBLINGS,CHILDREN" /> > > I believe that is at least intention from the code links below. I > personally have still not had luck recursively traversing through all > children and inline blips from the root blip when my robot is added to > a dense wave. > > See > also:http://code.google.com/p/wave-robot-java-client/source/browse/trunk/s...http://code.google.com/p/wave-robot-java-client/source/browse/trunk/s... > > On Nov 24, 5:18 am, Olreich <[email protected]> wrote: > > > The only remaining question is: > > > Can one specify both parent and child context, and thus get all > > blip_data with a single event? > > > On Nov 23, 10:53 pm, cmdskp <[email protected]> wrote: > > > > @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/sa... > > > > 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... > > > > "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 <[email protected]> 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 > > > > > [email protected]. To unsubscribe from this group, > > > > > send > > > > > email to [email protected]. 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 [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.
