[tdwg-tapir] ideas & TapirLite

Steven Perry smperry at ku.edu
Thu Nov 17 18:41:23 CET 2005

I suppose we could implement an optional "conversation id" or "request 
id".  I've used this kind of thing before when implementing some of the 
FIPA protocols for distributed intelligent agent systems.  This will at 
least provide a hook to build on top of, so long as it's optional.

What bothers me about it is that it starts to make the protocol look 
transactional.  Right now TAPIR is a simple, stateless protocol.  That 
makes it easy for us to implement it over the top of HTTP. Once we start 
talking about distributed, or especially asynchronous processing of 
TAPIR messages, things get complicated.

If TAPIR becomes asynchronous, clients will have to have a mechanism to 
cancel a request before they get a response (meaning free up state and 
move on).  To do this properly, TAPIR requests should be given a time to 
live so that downstream services that process requests can also cancel 
and free up state when necessary.  We may also need to give the client a 
method for telling the service it's talking to that it should not pass 
requests down or should only do so to a certain depth, in other words 
for the client to have some control over how it's request is serviced.

In summary, we may need several additional mechanisms to make this a 
stateful asychronous distributed protocol.  I'm not against adding a 
request id attribute, but going much beyond that will require some 
serious thought as to the implications.


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?
>The other thoughts were about TapirLite.
>We both think its a very bad idea to push all responsibility to the client by allowing any TAPIR service to be very minimalistic. If a client should be able to contact services that have different operators, operations and concepts, then I dont think we will get anything interoperable.
>I still prefer that these things must exist in the most basic TAPIR service. Otherwise we should call it different - maybe even TAPIR Lite as a valid subset:
>- all operations
>- all logical operators
>- the main COPs (<=> like)
>Cconcepts and response models can be optional without much problems I think.
>What do you think? should we sacrifice all this to have few clients but many providers?
>BTW, I think we didnt specify anywhere in capabilities if GET or XML Messaging is supported. So the idea is to always have both for all services, right?
>tdwg-tapir mailing list
>tdwg-tapir at lists.tdwg.org

More information about the tdwg-tag mailing list