Poll of opinions for new keyword

[Alan DeKok]

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