[Devel] MI protocol enhancement

[Dan Pascu]

On Tuesday 28 November 2006 13:49, Bogdan-Andrei Iancu wrote:
> Dan Pascu wrote:
> >it's not an issue for STREAM like connectins that close after the
> > command, but it is if they don't.
>
> as it is about OpenSER to client part, openser will always close the
> communication after sending the reply. otherwise it will be a bug :)

currently yes, but in the future it may become an option.

> >I think this is important to do for STREAM connections as well. What
> > if I don't want to close the stream connection after a request, but
> > want to keep it open and issue multiple commands on it?
>
> well...this is an open subject - if a stream connection should be
> reused for future commands or closed after the first one. but we have
> them both (as a matter of configuration) - also the commands may
> include such information (if the client wants to keep the connection up
> or not).

probably having the client include its preference would be better than to 
have them statically configured, but having a static default in case the 
client doesn't mention its preference is desirable as well.

>
> >Besides it won't hurt to have 2 LF at the end of the message, no
> > matter what kind of transport they use, it'll only make the messaging
> > clearer and more consistent across all MI implementations.
>
> it will not hurt I guess, but this will apply only to the text oriented
> transports (not for xmlrpc or http).

That is obvious. Those transports have their own encoding that assures 
that you know when the request/reply ends.
I guess I addresses them too broadly by saying "all transports", but I was 
only referring to the openser internally developed protocols that are 
line oriented.

-- 
Dan