[tdwg-tapir] ideas

[Renato De Giovanni]

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?