[Devel] MI protocol enhancement

[Bogdan-Andrei Iancu]

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.
>
>  
>