Renato De Giovanni
renato at cria.org.br
Fri Nov 18 14:24:28 CET 2005
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
* 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
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
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
More information about the tdwg-tag