[Mono-list] More thinkings

[Martin Coxall]

> The high-level pieces (Winforms, ADO) will need binding with the
> appropiate libraries as well.

The following thoughts have been disturbing my sleep of late. Help me rest.

Microsoft has insisted on including Windows-specific classes in the System 
namespace. In particular what are we going to about the following classes?

1. System.Data.OleDb.*

Are we going to wrap these so they simply delegate to the analogous 
System.Data.Sql classes? Or should we not implement them at all, so anybody 
who tries to use legacy code gets a class not found error at runtime? Or, and 
this is my favourite, create the classes to throw a 
Mono.WindowsLegacyException if anybody tries to instantiate one?

2. System.EnterpriseServices

These classes provide a full range of enterprise-level functionality such as 
coordinated transaction processing and asynchronous message queuing, through 
COM+. We could provide similar classes, perhaps by c#ifying the java code 
from the JBoss and Enhydra projects. But this may be a large job. Or, are we 
going to leave this assembly to one side for a while?

3. System.Security.PassportPrincipal and System.Security.WindowsPrincipal

I'd like the first one to throw a Mono.PrivacyThreatException and the second 
to throw a Mono.WindowsLegacyException, when you try to call a static method 
or instantiate one. Or, are we going to simply leave these classes out, and 
implement our own classes using the IPrincipal interface? 

e.g. System.Security.UnixPrincipal, System.Security.DotGNUPrincipal

Or, are we going to bite the bullet and implement PassportPrincipal so that 
.NET applications that use Passport can work on GNU/Linux and whatever other 
platforms Mono is ported to, even if we are playing into the hands of the 
Beast of Redmond?

Your thoughts gratefully appreciated.

---
Martin
---

"Where laughing and smiling are not allowed"