When you say it must remain binary compatible this should not be a problem surely for the new api?
For example, the System.Net.Security namespace is in it's entirety composed of stubs atm - so, *copying* code into there from the existing tls class will neither break existing applications but will start to work towards support of proper v2.0 api. I'd consider the moving to the new APIs to be the most important aspect, then DH implementation can be made far easier by comparing the .NET Framework's response to various DH servers with the Mono one as I implement it. With this in mind, I think I am going to start working on migrating the API as my first priority. It isn't that much fun, but it has got to be done! Martin On 11/6/05, Sebastien Pouliot <[EMAIL PROTECTED]> wrote: > Hello Martin, > > On Sun, 2005-11-06 at 15:44 +0000, Martin Hinks wrote: > > First task I think is to standardise between the two classes (.NET and > > Mono) so that (for example) handshake is intiated on the command, > > rather than just when data is attempted to be sent (as it is atm)... > > Ok but remember that Mono.Security.dll API must stays binary compatible > with existing code. This limits the number of changes that can be made > to it. GotDotNet's WinChurn can help you detect "breaking changes" and, > when some changes are just "potentially" breaking, you'll have to dig > more information (there are some good docs on MSDN). > > I think it will be easier to break the (a) add DH support and (b) move > to the newer API as two different tasks. > > -- > Sebastien Pouliot > email: [EMAIL PROTECTED] > blog: http://pages.infinit.net/ctech/ > > -- Martin Hinks http://www.m-s-d.net _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list