[Mono-dev] .Net 2.0 Question

[Martin Hinks]

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 <sebastien.pouliot at gmail.com> 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: sebastien at ximian.com
> blog: http://pages.infinit.net/ctech/
>
>


--
Martin Hinks
http://www.m-s-d.net