On Sep 7, 2017, at 6:25 AM, Matthew Newton <mcn@freeradius.org> wrote:
Best I could come up with yesterday (tweaked slightly again here) was something like:
I think splitting the functionality into pieces is best. That way it's more under user control. It requires care and attention, but it's *clear* at least.
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.
call [virtual-server].Access-Request
Yeah... tho minor tweaks to the syntax may help, in order to fit it into the horrible parser. :(
update parent { reply:Reply-Message := &Reply-Message } }
so splits off defining what lists contain what before actually forking. So you could potentially update control or reply lists before calling the virtual server as well.
That makes sense.
The protocol is defined by the namespace of the called virtual-server, so I don't think that needs setting here.
Yes.
This does give the ability for the child to update the parent afterwards, but I'm not sure how or where that would happen in practise (it likely couldn't without a wait)
Yes. The unlang compiler could probably be updated to notice that, and complain about it. So then the server doesn't start, but the admin at least gets a good error message as to *why* it doesn't start.
so I guess without that then your syntax is more concise. Not sure if it's as clear - I quite like the separation between creating the sub-request and setting up its attribute lists, and then calling the virtual server, as two distinct things.
I agree.
There's debate about what <keyword> should be, and whether there should be multiple <keywords> for async - where we split the lifetime of the sub-request from its parent, and synchronous behaviour - where we wait for the sub-request to return before we continue processing.
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...
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. Alan DeKok.