On Tue, 1 Feb 2011, Juan Lang wrote: [...]
I may be flogging a dead horse here, but I personally am loath to see another implementation creep in, side by side with the existing one, that has no guarantee of working any better.
As far as I understand it's not going to be another implementation. But you're probably right to warn about having multiple backends; that can be bad too as has been seen with sound.
Worse, even if you succeed in fixing bugs for your Mac customers, the rest of us don't benefit, as the current implementation still isn't getting any support.
Not true. Anyone using Wine on Mac OS X will benefit by not having to hunt down for a non-standard library to either compile or run Wine. That means Mac users will be more likely to actually have a somewhat functional schannel. Even those who use a packaged Wine will benefit because it means they will no longer either receive an outdated GnuTLS library that contains vulnerabilities with their Wine, or have to hunt one down on their own, or have no schannel support.
You say that schannel needs a lot of improvement and you say that we/the community should work on that first. However making schannel perfect will not make the dependency on GnuTLS any more acceptable on Mac OS X. So both need to be done it's only a matter of 'in which order'?
Option 1 1) Improve Mac support 2) Improve schannel Drawback is (1) makes (2) much harder but this has not been conclusively proven.
Option 2 1) Improve schannel until it's 'good enough' 2) Improve Mac support This means _most_ Mac users won't get any schannel support for a long time. And in terms of development it means a big refactoring phase near the end which may well be pretty disruptive too (hopefully it wouldn't be as bad as the display backend or DIB engine refactoring).
Not that I care about schannel anyway.