Dan,
I agree that adding an end-reply marker (an empty line) will do good
without any drawbacks. Maybe you can upload the request as a
Feature-Request on the tracker not to forget about it.
regards,
bogdan
Dan Pascu wrote:
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.
_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
