They did design it that way - but it doesn't mean they designed it to not allow it - you're inferring too much from two words.
If something doesn't offer an option, it doesn't mean they purposefully decided against that option - omitting something doesn't mean it was deliberate. It's a statement to explain it's about the design - not flippancy. After all, the sentence continues to explain the design with respect to 'context' which provided you with your answer as to what was possible and how it worked to the best of my knowledge. If I had not actually helped by answering your question with information in the same sentence then I would agree it would be flippant. As it is, I think you misread my intentions badly. On Nov 20, 12:26 pm, Olreich <[email protected]> wrote: > I must apologize then. "By design" implies that they designed it to > not allow for it. And thus, the question of it's purpose is natural. > "By design" is deliberate, thought out. It's also flippant and means > nothing, and I was grasping for answers, so I took the most meaningful > route. It happens I suppose, though I am sorry to mis-quote you. > > On Nov 20, 12:30 am, cmdskp <[email protected]> wrote: > > > I didn't say anything like you thought I did above on the Issue > > Tracker. I even provided you with the answer about the new robot API > > allowing access to other blips in the future in my first reply - > > nothing about purpose or that you're not supposed to, etc. > > > On Nov 20, 4:10 am, cmdskp <[email protected]> wrote: > > > > 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=.
