> Isn't that a bit of a red herring? I may have missed > something earlier, but why couldn't the effort that went in > to writing it in the linux environment been spent on a native > implementation instead?
Because the Linux-based implementation was a matter of compiling an existing implementation of the actual SSL engine from AIX and writing a tiny bit of glue to connect it to the VM stack versus developing a full-scale multitasking SSL server under CMS. That's not OpenSSL under the covers -- it's the internal toolkit used by other IBM products. Why? Because there are less legal hassles involved in using it. In all fairness, SSL is NOT a trivial thing to implement. There are a large number of crypto algorithms, and a lot of stuff that would be a lot of work to write and test -- and if they did do that work, we'd be hassling them about certification. Starting with a working, well-tested implementation isn't a bad thing -- IBM used the time saved productively on other things. The current implementation has flaws, and is messily integrated, that's a given. We've worked around those, and the SSL Enabler removes the argument about extra cost. I wish IBM would formally bless it, but c'est la vie. Now that there is a no-charge solution to enable SSL ubiquitously, there's no need to beat the horse about whether SSL is available or not. It is. Get the support and turn it on. Now, the functionality issues that Mark raises -- that's a different matter. Those need to be addressed regardless of how it's implemented.
