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 _______________________________________________ Devel mailing list [email protected] http://openser.org/cgi-bin/mailman/listinfo/devel
