RE: [bt-spec] BTP Issue 84 : What determines one-shot is used

[Peter Furniss <peter.furniss@choreology.com>]

 Mark Little sent:

 

 So are you suggesting that we specify precisely which BTP messages can be boxcarred and under which circumstances? At first glance this would also appear to mean that the single endpoint concept (doWork I think we're currently calling it) loses more significance, since this would be better addressed at the "interceptor/filter" level, which we're not defining anyway. 

 

 

I think we do have to identify which sets of messsages can be "related" - sent together with some semantic implied by the combination. (this is touched on in issue 85).  The one that applies in this case would be that ENROL and PREPARED, sent related to a CONTEXT_REPLY are to be sent to the Superior identified in the corresponding CONTEXT.

 

More general boxcarring ("bundling" in 0.9  - "facultative boxcarring" is an alternative term) doesn't need specifying in detail - the rule for it is just that if the binding addresses match, you can bundle the messages together.  The receiver (which generated the address(es) in the first place can be assumed to sort out what to do with them, or it wouldn't have let the addresses have the same binding address. They can have different "additional information".

 

That general boxcarring is really a particular case of the single endpoint - because we have the two part address structure, it is very easy for an implementation to ensure that everything sent to it passes through a single endpoint, by juggling the addresses it emits for itself - they all have the same binding address, which is that of the endpoint. If they then need to be passed on to something else, the "additional information" can carry the information needed for that endpoint to send it on correctly.

 

Actually, since the application generally won't have a compound address, the thing at the endpoint may be an interceptor/filter (i.e. be on the direct path to the application) anyway - diverting BTP messages if needed, but with the application as the default destination. But that would be an implementation choice - we don't need to define interceptor/filters as such - as we're just saying what goes in the headers etc., not how it got there.

 

Peter