[Mono-dev] Silverlight early implementation thoughts.

[Miguel de Icaza]

Hello Joshua,

> IMO, the Mono community/project tends to spread itself very thin. Lots 
> of things get started but not polished up and finished very well. I 
> don't think that's always a bad thing --- in fact, the renewed 
> enthusiasm that tends to follow new APIs from MS, for instance, is 
> really nice to see. And it's certainly not without exception -- 
> MonoDevelop is polished, and impressively so despite the fact that it 
> continues to undergo significant progress.

I agree with you.

There are certain projects that we have abandoned or that we have
outright decided not to implement due to this nature (the various WSE
attempts for example, some of the EnterpriseServices projects,
maintenance of third-party libraries). 

> But the unpolished things include:
> 
>    Debugging (MD integration, or *some* GUI debugger)

Yes, the issue here is that the debugger has only recently became
complete enough to debug applications, and even then, it is still
missing support for certain features (some people report issues with
AppDomain debugging).

It is now possible to build some integration with it, but it was
impossible before we had the debugger working.

>    mod_mono (configuration is very awkward, problems are hard to 
> diagnose, restarting the Mono process is still strange)

Mod_mono configuration is the area I hate the most about Mono, for one I
can never remember how it works and I *always* have to look up the
manual pages myself. 

I guess that part of the problem here is that we never defined a clear
goal in terms of what the end-user experience was.   Auto-hosting was a
step in that direction, but am not sure that we have explored all the
areas here (recently I had some issues, but I forgot to take notes, and
I can no longer remember what was it that annoyed me so much about it,
but I know things annoyed me).

>    Class library documentation
>    Doc tools for independent libraries (we need a proper editor GUI)

Yes, I wish we had one.   Maybe one will come out of the Summer of Code,
but you never know.

In general, I have tried to get people to write documentation when they
write their code (inside my team).   Some people do not like writing
docs, but also there is the fact that although docs are important, we
always have someone screaming for an urgent task to be fixed.  So urgent
tends to trump important. 

> (Some may know that I've taken small stabs at improving the last three 
> over the years, and I'm guilty for leaving things in unpolished states.)

And am incredibly thankful for this work.

> Other random things that I think are important:
> 
>    The new GC

It continues to be under development, although Paolo has been pulled
into a few projects every once in a while, so this has slowed down
progress.   

For a while we only had Paolo and Massi working on the JIT, a situation
that is changing as Zoltan joins the team again, and two new JIT
developers start in May and June.

>    Runtime performance

This is not for lack of trying.   

A few months ago we got a major boost from the work that Massi did for
almost six months.   There are large projects underway, Zoltan's
linear-il branch will be the future base for optimizations and Massi was
working on a new register allocator for it, but we changed directions
during Massi's research.

I wish for one that Massi blogged more often, because the tale of what
happened ended up merely on a discussion in our internal mailing lists
and our internal emails.   And as Jon Udell was saying a few days ago,
this is not a good way of maximizing keystrokes, this should have been
blogged or posted.

But the story goes like this: Massi was working on the new register
allocator (the major source of pain for the extra spills/reloads in our
code generator) and noticed that a lot of passes could be avoided if we
just made our JIT work only with SSA-based representations.  He
consulted with me, the performance loss was not significant, so I told
him to keep working on it.

Then we discovered that JIT time although not an issue for large systems
would be a big issue for embedded devices (things like the Zing) so we
reset the work to go with the original plan, loosing the SSA-only setup
(the whole story is more interesting, but am trying to keep this short).

Anyways, Massi was doing this, when we realized that people were
adopting GMCS in droves even if it is not supported, and a problem here
was that Arrays were creating thousands of interfaces (because of all
the implicit interfaces implemented).   In an app like Banshee, 1 meg
gets JITed and 1 meg ends up being allocated for vtables! (vtables were
basically empty).

So Massi has gone to implement a way of compressing the vtables as this
has much higher priority than improving the performance.   But these are
not one-week hacks, these are multi-week changes, and the register
allocator is a six month effort for example;  The linear-ir branch is
probably going to take a year before it can be rolled out.   Nothing
visible immediately.

Anyways, it is a world of small tasks like this.

>    Was CAS ever finished?

No, it has not.   And we do not have right now plans for when this will
be finished.   The CAS was too hard to use (even in .NET) so we might
end up first implementing the Silverlight-like security system before we
get around to doing CAS.

>    AOT on 2.0 assemblies (at least for non-generic types)

This is a wish-list item at this point, it would be nice, but am not
sure when we will get to it.

>    Internal testing of the Web pipelines, by having mono-project.com run 
> on the Mono stack

If someone writes a MediaWiki replacement that is *compatible* with the
MediaWiki database and rendering interface, am fine switching to it.   

> And that's just what comes to mind right now. (SWF, ASP.NET 2.0, and 
> finishing the existing APIs go without saying.) There are a lot of parts 
> of Mono that I've never even touched that I'm sure have unpolished 
> aspects too.

I agree, and they are being worked on.   There are currently six
engineers working on it (Sebastien is working on GDI+/System.Drawing,
but mostly because of System.Windows.Forms).

> OTOH, since there are people being paid to work on Mono, it doesn't hurt 
> to suggest what I think their priorities should involve---namely, 
> polishing existing parts of the project.

Which is exactly what we are doing.

But am considering that we will likely cut pieces or re-arrange the
schedule and roadmap for the sake of Silverlight, for one because a lack
of Silverlight in Linux would prevent us one day from useful content. 

But its still up in the air.  I know what am going to be spending my
weekends on ;-)

> And, besides that, before Mono hackers get too involved with an entirely 
> new API that may very well flop, I think it would be useful to consider 
> whether there are existing parts of the project that need polishing that 
> you'd also enjoy working on.
> 
> My two cents.

Silverlight could go both ways though: it could flop or it could change
the way we build Web applications entirely.

Miguel.