[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.
-Steve
Döring, Markus wrote:
>Hi,
>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?
>
>
>Markus
>
>
>_______________________________________________
>tdwg-tapir mailing list
>tdwg-tapir at lists.tdwg.org
>http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
>
>
More information about the tdwg-tag
mailing list