I really should read the rest of a thread before jumping to reply to someone asking for an answer in a link above...
Anyway, qMax gave the same answer I just did on your issue Olreich. I didn't star the issue, so didn't get any notification. As you can imagine, this has been a feature lots of people have asked about and the answer appears dotted around in various places I've come across over the last month or so. When I said: 'This is by design.' it meant that the design is that way currently - purpose can't be inferred without more info than the exposed design offers. But you can see logic in it, from a number of perspectives: - Bandwidth - Speed of processing requests - Scaleability - Overloading wave servers etc. I look forward to the new design of the robot API so that my robot can perform across the whole wave as I hoped and others expect. On Nov 19, 5:46 pm, Olreich <[email protected]> wrote: > Sweet, thanks for that information. > > On Nov 19, 9:46 am, qMax <[email protected]> wrote: > > > qmax: > > in wave-api group it was asked, but asker seems missing here. > > will robots be able to access blips/wavelets out of scope of current > > event? > > > austin: > > robot has access to the context of the triggering blip, its immediate > > parent and child context. Anything other than it has no access to. > > > qmax: > > what if i build an operation manually, using waveid/waveletid/blipid > > out of context? > > > austin: > > you can perform action to that blip such as appending, etc. But you > > still have no context to its actual content, like if you want to > > parse > > out any FormElement within the blip. A new mechanism we are working > > is the active gateway API which will allow a robot to make active > > request to wave to retrieve full context of any blip. > > > On 17 ноя, 11:41, Olreich <[email protected]> wrote: > > > > The Java API has the Blip.getParent() function. When this is called, > > > the returned blip does not have the ability to "getParent()" again it > > > seems. or, at the least, one cannot continue walking without hitting > > > null on the second trial. The same rings true when using > > > "isParentAvailable()" to check for parents. > > > > Here is an excerpt of the code for walking up the blip chain. > > > > Blip currentBlip = bottomBlip; > > > Blip lastBlip = null; > > > while ((currentBlip = currentBlip.getParent()) != null) { > > > lastBlip = currentBlip; > > > > } > > > > This stops with currentBlip being exactly 1 parent above bottomBlip. > > > Every time. > > > > Sample Blip chain information: > > > > 12:21 > > > Blip Id: b+2ew83hhsK > > > Parent Blip Id:b+9k9iVrZkEzM > > > Parent Available: true > > > > 12:21 am > > > Blip Id: b+2ew83hhsM > > > Parent Blip Id:b+2ew83hhsL > > > Parent Available: true > > > > 12:22 am > > > Blip Id: b+2ew83hhsN > > > Parent Blip Id:b+2ew83hhsM > > > Parent Available: true > > > > 12:22 am > > > Blip Id: b+9k9iVrZkE0z > > > Parent Blip Id:b+2ew83hhsN > > > Parent Available: true > > > > 12:22am > > > Blip Id: b+2ew83hhsO > > > Parent Blip Id:b+9k9iVrZkE0z > > > Parent Available: true > > > > Using a bundle.getBlip(waveId, waveletId, parentBlipId) command to > > > travel also does not work, as it stops once more at the blip just > > > above. > > > > What appears to be happening is that each blip, upon a BLIP_SUBMITTED > > > event, has the ability to see it's parents and such, but when a blip > > > is found via any of the methods of "get" there is no parent > > > information on them. It would be most useful to have this worked out, > > > as then it would give us at least 1 way to reliably count blips, do > > > batch operations to blips, and a couple other fun things. > > -- 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=.
