On Mon, Jul 6, 2009 at 11:01 AM, Colin Campbell < colin.campbell@ptfs-europe.com> wrote:
On 07/06/2009 03:00 PM, Joe Atzberger wrote:
Colin --
Koha SIP can handle dossy ^M line endings just fine. The detection of line endings is essentially delegated to the IO::Socket::INET and Socket modules with local $/ = "\012".
The problem is that the protocol states that all messages end in a carrage return (hex 0d). There is no requirement to set linefeed as a terminator as it is not a message separator.
The stuff I mentioned are the particulars of the implementation. You are welcome to experiment with other components, but I think you would find unilaterally setting to \010 wil break far more than it will help. I agree with you on what the spec says, but at the time of implementation, ZERO clients available to Koha developers actually behaved that way, including the reference implementation from 3M. At this time, the number of such clients available to us is still zero. We would need more information about the clients in question: - What are they? - How widespread is their use? - Are they the *current* version of their implementation or orphaned legacy code? - Does the developer still support the implementation? - Are they open source? (you've suggested they are not)
I don't see any reason for a client to send hex 0a or any other control character in any message field.
It's allowed so they will. I've seen it on a number of occasions. It would also be "allowed" to renegotiate the telnet handshake midstream. Nobody does this. I'll restate my contention. The SC has a defined number of commands and those have a defined number of required and optional fields. None of the data to be communicated in those fields should legitimately contain hex 0a or other control characters. For example, if your branchcode contains a linefeed, Koha will break in many other places, including before you are able to get a full transaction response from SIP. When do you imagine it would be appropriate for a SIP client to send, for example, a BELL character or BACKSPACE character? It may be possible to make the line-ending an
attribute of the SIPconfig account, such that you could have a different one for a given SIP terminal. Or more likely, you can get the clients to send a different line ending.
This would be the way to go for flexibility. At the moment the assumption is interwoven with the protocol handling. I don't think expecting the clients to send different line endings is likely as these are usually closed (often windows) binaries.
You could still run a middle layer on localhost. But if it can be handled cleanly via SIPconfig, I would support that.
Its a lot easier to handle the vagaries of the clients in the perl code.
Maybe. I'm sure it isn't easier to develop a whole new SIP emulator to support testing on the new config though. --Joe