[Mono-list] ".NET 3.0" misnomer

[Miguel de Icaza]

hello,

> > If you could point out something that you think is fundamentally 
> > unimplementable, we could have a discussion about that feature. 
> > 
> 
> I'm guessing certain aspects are already easier to implement than WinForms
> (due to things like the dispatcher replacing the message pump), but really,
> no one expects Mono to be able to manage it. Most of us are more worried
> about whether Mono would actually take on the task than we are about whether
> or not it can be done.

That is a valid concern, but that has nothing to do with the portability
of 3.0;   It seems actually that all of 3.0 is more Unix friendly than
Windows.Forms was.

> Effectively Mono would be stuck at 2.0 while .NET is at 3.0, and "3.5"
> onward would be incomplete (like I wrote in the petition, the "3" would be
> missing). Even if that's not the truth about 3.5+, it will be the
> perception, and it will hurt Mono, which in turn will hurt .NET.

Well, am not too concerned about the label;  Today Mono is not even a
complete 1.1 implementation, it misses pieces like EnterpriseServices
and it is still very useful to people.

In the same spirit, we might implement C# 3.0 without implementing the
rest of the .NET 3.0 stack, but that does not mean it is not useful.  It
just means that there is no parity in version numbers (but even today,
there is no parity in version numbers). 

> So my question is this: will you do .NET 3.0?

It is too early to tell.

>From a personal standpoint, there are things I like, things I do not
like in 3.0, and am not sure how excited am about implementing those
ones.

>From a Novell point of view, if we find that implementing these might be
of strategic value for our Linux business (buy SUSE :-), we might look
at implementing those.

>From a community standpoint, it might very well happen that some of
those pieces are implemented by third-parties;  And the code could be
merged, or not with Mono.    

>From a project point point of view, tracking a moving API is difficult
and it would be best to invest our time on the APIs that are set in
stone instead of the shifting ones that 3.0 are at this point.   It is
too early to start getting alarmed at the falling sky.

I think that 3.0 stuff should be kept on a separate package, if only
because it would be a release nightmare otherwise (and I already would
like to split up some of the stuff in mcs/class into other packages, but
we haven't done merely because of logistical and resource
requirements). 

Miguel.