For other application protocols, such as SMTP, the special code sent
by the callout service can even make functional sense. A service may
want to send several error messages, all not longer depending on the
rest of the application data, to multiple recipient and therefore it
will send several application messages. By indicating with the first
AME that the OPES processor can stop sending more application data
it helps to increase performance.
It looks like you want one adapted AME status code affect behavior of
other adapted application messages (whether they are going to receive
more original data). I think a better interface would be to have a
special "Wont-Use" message with a transaction scope, to indicate that
more original data is not needed.
Here is the new message. I found it :-)
Hmm... It looks like we really do
not have a good enough interface to control original data flow in the
case of multiple adapted messages. It is currently not clear whether a
single adapted flow statement like Wont-Use parameter applies to
original data flow (and hence affects other adapted messages) or just
to the adapted flow making a statement. If we ever end up supporting
multiple adapted application messages, we would have to make all of
that clear and consistent.
For now, it looks like we assume that there is always a single
original flow, regardless of the number of adapted flows. Perhaps it
is the right decision (because it is simple), but it is hard to say
without digging into SMTP specifics. On the other hand, we stick
parameters like Wont-Use into am-id-dependent messages as if we imply
that two adapted flows may have different Wont-Use statements.
Do you think we should move all parameters that apply to the original
flow from am-id-specific messages to xid-specific messages? For
consistency reasons?
Yes, it makes a lot of sense.
Please introduce Wont-Send message and remove the parameter from DUM/DUY.
Or do you think we will eventually require
processor to merge all such parameters together before deciding what
to do with the original flow?
Will be a night-mare and probably end with interop-problems as expectations
at OPES processor side will probably be too easy.
In other words, who is responsible for
merging adapted flows' interests into one statement affecting original
flow, the server or the processor?
If a server thinks, it must create multiple messages and wants to use
Wont-Send
information it is responsible to get this done correctly.
However, I am not sure how to document the "short circuit" code in the
Core. The Core cannot assume that an application protocol has
requests/responses and, hence, cannot document something like a
"Respond with this response instead of forwarding original request"
code.
If I try to be generic and document the code as something like
"adapted message is not intended for the original message recipient",
we might raise red flags for those who think that IAB "OPES must not
resolve URIs" concern applies in this case.
Suggestions?
I do not see that you have to document a generic short-circuit thing.
In OCP core it is simply about receiving application messages back from the
service that are (not longer) depending on the original message.
Sending HTTP error messages in REQMOD is a prominent example and
real request satisfaction another but there are more examples, even for
RESPMOD and in real life:
1. Removing animations from GIF images are possible by changing few bytes
in the beginning of the image and the cropping the image data after the
first
picture. A callout service can return such adapted GIF and instruct the OPES
processor that it finished filtering even before it has seen the rest of the
GIF.
Further transmission is not necessary.
2. Very similar from AntiVirus area: There are BMPs known to contain
malicious
code after the real image data. A security service could delete them and use
the
207 result for best performance.
Do you now think, you can document that feature in core?
Martin