Reasons against unravelling recursion in lookup.

Alexandre Rafalovitch writes:
 > Working on a new resource I found a situation where I would preferred to
 > have recursive lookup instead of loop in a Client. Which does step by step
 > lookup.

Done in the next release :-) I thought that the loop was just
de-recursiving the process, but in fact it had more subbtle
effects. The way lookup is done in the next release has subttly
changed, as I mention in some previous mail about the new filtering
model.

 > What I needed to do is for parent during lookup stage to know if a
 > descendent resource does not exist. The reason I need to do that is because
 > in situation when child does not exist, I want parent to take some evasive
 > actions (basically return redirect instead of non-found).  It can be done,
 > if the child of DirectoryResource does not exist, but if it is further
 > descended, then it is impossible, because lookup of a child is done not
 > recursively from directory resource, but from a Client. Therefore Parent
 > never knows if a child is in trouble.

I think you will be able to do this with the next release of Jigsaw
(yep, I am nearly sure)

 > Also, current filter model does not let me catch errors either, because it
 > is not called on error. I know that next filter model should be able to
 > work differently and it would solve my problems (hopefully), but  until
 > then (RSN) I can't do anything.

I am working really hard to put out the release ...

 > This letter is not a request for solutions, even though such would be
 > welcomed, but a food for thought about what was the price of unravelling
 > recursive lookup call.

Correct (I mean we paid the high price).

BTW: While you seem to think a lot these days ;-) if you have any
other serious design flaws to mention, it is really the right time to
speak up. 

Anselm.