[Mono-list] Re: More thinkings

[Miguel de Icaza]

About implementing the classes, here are a few rules:

	1. Do not panic when you see something complex. 

	2. Never stop working on something because there is a bit
	   of unknowness ahead of you, or because you feel ignorant
	   about a piece of software you will have to write.

The reason for (2) is very simple, and the essence of the passion of
programming: the more unknown a subject is to you, and the more
complex it seems to you, the highest chance you have that it will be
one new domain of knowledge of computer science that you will get to
know and experiment.  The joy of programming comes from doing new and
innovative things.  So if you fear a bit of code, it is probably the
bit of code you will enjoy the most working on. 



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

They would come in phases:

	Phase 1: Not implemented.  If you try to run an app that
	requires the assembly where System.Data.OleDb is implemnted,
	it wont even start.

	Phase 2: Stubify.  Application will run, but will get errors
	when it tries to use the methods (maybe exceptions).

	Phase 3: Someone with the time or the need (need is what
	drives a lot of these contributions) investigates the problem
	and wraps SQL or anything else around the API described above.

So in general, we implement things as we need them.  I know what parts
Ximian needs the most (GUI stuff and Web Services) so you know what
kind of classes we are most interested in having.

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

I am not familiar with JBoss or Enhydra at this point to comment on
that.  But I have looked at the COM+ extensions over COM and had
always wanted to put that in Bonobo in a previous life.  Transactions
and async messages are not really that hard (we even designed a Bonobo
moniker to async-ify any method invocations, overall: a trivial
problem).

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

It is too early to decide.  I think that we need to look at how the
industry will react (and whether they will be competing Passport
systems).  

I have a few thoughts on passport (personal ones) and I will write an
article explaining those and the relation to Mono later this weekend.

Now, worst case scenario: since Mono is free software, you could
implement your classes in any way you see fit.

Miguel.