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