Poll of opinions for new keyword

[Matthew Newton]

On Thu, 2017-09-07 at 13:28 +0700, Arran Cudbard-Bell wrote:
> New functionality is being added in v4.0.x to allow new sub-requests
> to be generated by requests received by the server.
> 
> The basic format is:
> 
> <keyword> [virtual-server.]<packet-type> {
> 	<sub-request-attr0> := <parent attr0>
> 	<sub-request-attr1> += <parent attr1>
> 	<sub-request-attrN> += <parent attrN>
> }

Best I could come up with yesterday (tweaked slightly again here) was
something like:

  subrequest {
    update {
      request:User-Name = &parent.request:User-Name
      request:User-Password = &parent:User-Password
    }

    call [virtual-server].Access-Request

    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.

The protocol is defined by the namespace of the called virtual-server,
so I don't think that needs setting here.

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) 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.

> 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.

  parallel {
    subrequest {
      update { ... }
      call default.Access-Request
    }
    subrequest {
      update { ... }
      call default.Access-Request
  
 }
    group {
      some
      normal
      module
      calls
      here
   
}
  } # implicit wait here

  other
  modules

would run two subrequests and a load of module calls in the original
request simultaneously, and wait for them all to complete before
calling "other" and "modules".

"group" is probably redundant, as you couldn't have two groups (one
would have to be a subrequest, or they would get called sequentially
anyway)

> The original keyword was "fork", and has since been changed to
> "create".  Do people have any opinions on what the easiest to infer
> and most consistent keyword to use here would be?

Only really that fork only makes sense to programmers, and that's not
helpful in making the server easier for most people.

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).

> There's no guarantee that the most popular keyword/idea will be used,
> but it'll at least inform us of general public opinion :)

Things like this are hard to get right, so ideas are definitely helpful
:)

-- 
Matthew