On Thu, 2017-09-07 at 09:23 -0400, Alan DeKok wrote:
On Sep 7, 2017, at 6:25 AM, Matthew Newton <mcn@freeradius.org> wrote:
subrequest { update { request:User-Name = &parent.request:User-Name request:User-Password = &parent:User-Password }
And if you want to run it asynchronously:
detach
which would explicitly detach it from the parent.
That's nice, I like it. 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. 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 subrequest. That's very clear behaviour, which is good. 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? 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.
Thought on waiting was that you don't, unless the whole lot is in another block, say "parallel" or "concurrent" which enforces a wait for the children at the end, e.g.
For various reasons, the "parallel" section already creates sub- requests...
Ah, yes, I forgot about that. Maybe doing a "wait" instruction is better than arbitrary blocks anyway. Hmmm... recv Access-Request { subrequest MyProxy { update ... detach call virtual-server.Access-Request update stuff ... } subrequest MyLoggingThing { ... detach ... } eap pap wait MyProxy linelog wait # by default wait on all subrequests, as none specified }
I think a lot of the syntax comes down to what happens when the child request *finishes*. Where does its reply go? If something needs to happen then the syntax needs to allow for doing that (even if it might in future).
update { parent.foo = bar }
That's the only answer which makes any kind of sense, unfortunately.
Looks OK to me. update parent { request:foo = bar } Would also be nice, or "update parent.request". -- Matthew