[Mono-dev] Silverlight early implementation thoughts.

Sun May 6 07:20:29 EDT 2007

Hello,

Although I agree on those challenges as important goals for Mono
platform, Moonlight (BTW, really good idea for this codename)
shouldn't wait so much at the wardrobe.

In the next months, if everything goes fine for Silverlight
development, it may become a really powerful tool for Web developers.
Once 1.0 is out, or 1.1 some months later, there could be two
hypothetical options:
1. Mono has no support for it. If Silverlight success, there could be
a large switching from ASP.NET 2.0 model to Silverlight (probably
similar to Flash movement), but Mono will continue one step behind.
ASP.NET 2.0 may lose all the weight it currently has.
2. Mono has support for it, at least for rendering content, not own
tools for designing, etc. If Silverlight success, GNU/Linux users will
take part in their platform deployment from the very beginning.

Web developers, when deploying their Silverlight applications will
realize it's possible to work also on GNU/Linux, for sure acquiring
interest in it. A big goal for Mono.

I haven't forgotten the possibility of Silverlight not succeeding, but
if it happens, most of the work done will just be reused into another
project, like LINQ, SandBox, etc.

It's currently quite difficult to determine whether what developers
will like to work with from now to a year or two but, honestly, after
Flex 2, Silverlight, and so on, it looks like a big switch is
happening.

It's been very exciting to see these entries at Monologue talking
about this baby-project. :-)

My two bits.

Regards,

One who wants Moonlight to become real. ;-)

2007/5/6, Miguel de Icaza <miguel at novell.com>:
> 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.
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>

-- 
Marcos - http://www.youcannoteatbits.org