On Sep 7, 2017, at 10:36 AM, Matthew Newton <mcn@freeradius.org> wrote:
So doing a subrequest {} block (or whatever it ends up being called) is essentially just a block which has its own attribute lists, so a space for local variables that won't mess up the main request. It runs in sequence with everything else, and at the end processing continues at the next instruction in the calling block.
Yes.
But as soon as you call 'detach', you've forked. You can never return from this request to the parent, and the parent immediately starts to continue at the next instruction after the sub request.
Yes.
The only issue I can think of, are there ever any cases where you want to detach (maybe once, maybe more times), but then later on update something in the parent?
Nope. Once it's detached, the parent can *go away*. So there's no way to update the parent, as it doesn't exist.
If so, maybe you also need "wait" as well as detach. That sits in the parent, and waits for all subrequests to finish. At which point they could have updated the parent.
That's what "parallel" is for.
update parent { request:foo = bar }
Would also be nice, or "update parent.request".
The "update parent.request" syntax is already supported. Alan DeKok.