The root node is returned along with the children in
WAVELET_SELF_ADDED and context="children". Here's my capabilities.xml:

<?xml version="1.0" encoding="UTF-8"?>
<w:robot xmlns:w="http://wave.google.com/extensions/robots/1.0";>
  <w:capabilities>
    <w:capability name="BLIP_SUBMITTED" content="true"
context="children" />
    <w:capability name="WAVELET_SELF_ADDED" content="true"
context="children" />
  </w:capabilities>
  <w:version>1.0</w:version>
  <w:profile name="CleanTXT" imageurl="http://cleantxt.appspot.com/
imgs/icon-caution.png" profileurl="http://cleantxt.appspot.com"/>
</w:robot>

It appears, inline comment blips are also returned.  I don't need any
separate processing added in the Java API for them - my robot
[email protected] processes them too on WAVELET_SELF_ADDED.

My delete test robot only processed all blips on the
WAVELET_SELF_ADDED event - the BLIP_SUBMITTED was picked up, but not
used.


On Nov 24, 11: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.


Reply via email to