Poll of opinions for new keyword

[Alan DeKok]

On Sep 7, 2017, at 6:25 AM, Matthew Newton <mcn at 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.