Poll of opinions for new keyword

[Matthew Newton]

On Thu, 2017-09-07 at 09:23 -0400, Alan DeKok wrote:
> On Sep 7, 2017, at 6:25 AM, Matthew Newton <mcn at 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