Re: Channel response serialization

> I'm curious about the justification for the requirement that responses to
> queries on a channel be in the same order in which the queries were issued.
> I understand that it has been stated that this simplifies the protocol
> implementation. Does this mean that it simplifies the protocol or the
> libraries that implement it? If its just the libraries, couldn't the
> serialization requirement be made optional (i.e. part of the session
> negotiation)?
> 
> I ask because it seems that this excludes a large class of applications from
> using BEEP, so that those of us who need truly asynchronous messaging are
> left with the same problem that BEEP was intended to solve. Namely: HTTP
> doesn't quite fit and SMTP doesn't quite fit.

hi. you're right: it's probably a silly limitation in that the only thing that it makes "simpler" is the implementation on the side receiving the responses. (the side generating the responses couldn't care less, right?)

i guess my question though is why not use the MSG/ANS approach to dealing with this? without understanding what the traffic looks like for the class of problems you're interested in, i can't really comment more.

/mtr