I tend to agree with Steve here, and I think we should be careful when trying to accommodate more different services with the same protocol. I'm not arguing about the usefulness of having services like:
* Give me a complete dump of this huge data source. * Do a search in all these networks using some criteria, keep trying for "n" days if any provider is down, and then return to me a report.
The problem is that there are certainly more things that would need to be considered in the protocol so that we can safely cover new scenarios.
If our data provider implementations will remain stateless (which is the case right now), even if we only include a new "request-id" element in the protocol, it would only be used to interact with these new top-level services, not with the "real" providers.
Maybe TAPIR could be wrapped by another generic asynchronous protocol? Or maybe those different services could try to use TAPIR extension hooks for their specific purposes? (the request-id could be inside /header/custom for instance). Although personally I would prefer to use a ticket-based approach instead of making the client send a request-id.
So (currently) I would suggest to keep TAPIR completely focused on a stateless world. -- Renato
On 17 Nov 2005 at 16:25, Döring, Markus wrote:
talking to Anton today we were wondering if it makes sense to allow a tapir client to embed its own request-id into the tapir headers for later identification of asynchronous and distributed messages. Currently we would need to identify a message by its sendtime (vague) and source.
Does this make sense? Does anyone know how other people deal with this problem?