this is drifting into the realm of new functionality
which Ian expressly deferred until v2.0 on the last
con call.
We concluded long ago that the conversation was the
boundary for sequenced order of message delivery.
Conversations are NOT intended to be never ending.
A conversation is the bounded series of messages that
constitute a single instance of a business process.
(e.g. QouteRequest->PaymentAcknowledgment for a single
purchase). Conversation is not intended to be the
boundary of all messages exchanged between two
parties.
A non-normative note along the lines that Marty suggested
should be more than adequate.
Cheers,
Chris
David Fischer wrote:
> Marty,
>
> I was suggesting first that we might not need messageOrderSemantics and we could
> do away with this attribute.
>
> I was suggesting second, that it is not particularly useful to tie MessageOrder
> to ConversationId. I did not mean to imply that MessageOrder would be outside
> the confines of a Conversation. We have no means of ending a Conversation and I
> suspect it will be common for Conversations to never end (why should they?). We
> do not specify that a ConversationId must be kept in storage anywhere in the
> spec.
>
> I am looking for another way -- say a new set of ordered messages could include
> the start number so the Receiving MSH does not have to keep messages past
> persistDuration? I don't know the solution but I think MessageOrder is broken.
> IMO, keeping information in persistent store forever is not the right answer,
> but I will go with that if it will get us past this problem.
>
> David.
>
>