[Devel] MI protocol enhancement
dan at ag-projects.com
Tue Nov 28 13:20:45 CET 2006
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
More information about the Devel