Subject: Re: Questions on TransactionReply

From: Brian Rosen <[email-masked]>
Date: Fri, 29 Oct 1999 14:20:01 -0400

The question applied to a transaction that could not be parsed.  In that
case you don't know what the transactionId was.
If you can parse it, you should return it.  If you can't, you use a null
transactionID, because you don't know what it was supposed to be.

Brian

> -----Original Message-----
> From: Abdallah Rayhan [mailto:[email-masked]]
> Sent: Friday, October 29, 1999 11:32 AM
> To: Brian Rosen
> Cc: [email-masked]
> Subject: Re: Questions on TransactionReply
>
>
> Brian Rosen wrote:
>
> > > 2. The last paragraph says "If the receiver encounters an
> error such
> > > that it cannot determine a legal transaction, it will return a
> > > TransactionReply with a null TransactionID and a single error
> > > descriptor." What is the purpose of the error descriptor
> if you don't
> > > know the transactionID? How does one use such an error descriptor?
> >
> > You know when you send a Transaction Request.  You expect
> to get some kind
> > of reply.  While a reply with a null TransactionID is not
> as nice as one
> > with a transactionID, you can probably still figure out
> what you need to do.
> > Any reply is better than no reply.
>
> A transaction reply should have the same TransactionID as the
> request even
> in case of error. Transactions are not supposed to be
> processed in order or
> replied in order. If you have 10 transactions and have 5
> replies with null
> transactionIDs,
> do you want to waste your logic to match things up.
>
> Why should we complicate the programming logic if we can
> simplify things at
> the semantics level.
>
> Abdallah Rayhan
>
>

---

From: Abdallah Rayhan <[email-masked]>
Date: Fri, 29 Oct 1999 14:32:49 -0400

Agreed.

Abdallah