[Mono-dev] .Net 2.0 Question

[Sebastien Pouliot]

Hello Martin,

On Sun, 2005-11-06 at 16:59 +0000, Martin Hinks wrote:
> When you say it must remain binary compatible this should not be a
> problem surely for the new api?

That was about modifying Mono.Security.dll and not about adding support
for System.Net,Security.

> 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.

I'm not sure it's the best course of action (feel free to disagree ;-).
You'll get DH working a lot faster by adding it to Mono.Security.dll
than porting the SSL/TLS code in System.dll - and has the added benefit
of providing SSL/DH support for users of the 1.x frameworks.

> 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!

As I said earlier, Carlos was working on porting his code to System.dll
(not in SVN). You should get in touch with him before starting any port
of your own or you'll likely lose a lot of time (which would be sad
considering there are a lot of interesting stuff to do in Mono ;-).

> 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/