[Mono-dev] Silverlight early implementation thoughts.

Sun May 6 08:19:21 EDT 2007

Hello Joshua,

You raise some good and valid points. Of course I see them as "good and
valid" because I share them ;-) but my conclusions don't match yours.

On Sat, 2007-05-05 at 18:09 -0400, Joshua Tauberer wrote:
> Miguel wrote:
>  >     Silverlight brings another component into the equation:
> 
> Hey,
> 
> I don't think I usually chime in on these things, but this time I 
> figured I would.

as do I ;-)

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

I don't think 3.0 and 3.5, even together, showed much enthusiasm
compared to 1.0 and 2.0. At least Silverlight seems to beat that.

> And it's certainly not without exception -- 
> MonoDevelop is polished, and impressively so despite the fact that it 
> continues to undergo significant progress.
> 
> But the unpolished things include:
> 
>    Debugging (MD integration, or *some* GUI debugger)
>    mod_mono (configuration is very awkward, problems are hard to 
> diagnose, restarting the Mono process is still strange)
>    Class library documentation
>    Doc tools for independent libraries (we need a proper editor GUI)

I think the previous emails answered most of them.

> (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.)
> 
> Other random things that I think are important:
> 
>    The new GC
>    Runtime performance

True, but both tasks are, in large parts, unrelated to the API being
targeted. Interestingly the related parts may make those tasks easier
(to do or to prioritize) in a smaller subsystem.

>    Was CAS ever finished?

No. Lots of interdependent reasons for that. Without stealing the thread
subject (there's been enough email about it) I think we can quickly
generalize most of them under the "Lack of interest" category.

E.g. of all attendees to last October Mono meeting only a single person
had used (well tried) the --security option, namely Paolo (I excluded
myself from the count ;-).

        No, I'm not blaming anyone over that. Reality shows that people
        expect desktop applications running with FullTrust and that
        other solutions exists for web apps (otherwise a lot of other
        environments, like PHP, would never have risen). However I don't
        put much believe in the fact that "people waits for full CAS" to
        explain this, CAS always existed under MS runtimes and the
        situation there isn't very different.

Perhaps one of the hardest thing to do is coming with a *useful*
multi-step implementation plan. It's hard to see intermediate states,
between the current code and a fully functional CAS implementation, that
would be useful to many.

        E.g. MWF required a lot of work (several people, several years)
        to get many existing Windows applications working without
        changes. Even then it can be useful with a subset of all
        controls (e.g. WebControl). CAS without File permissions (or
        Sockets, unmanaged code, verifier checks) wouldn't be useful at
        all.

This makes it hard to invest into the "next step" knowing the dividends
are far and away - and I'm not just talking about Novell here, same
applies to individual contributors. As you stated there is so much
things that would get more immediate, and positive, results.

Now back to the original subject, Silverlight, may be providing a useful
step. From the (very) little I've seen so far I don't believe it's very
different from CAS (there's not many ways to run untrusted code). This
translates to:
        - less work than a full CAS implementation (i.e. quicker
        dividends)
        - a smaller Fx would requires a smaller audit (still a big task,
        but a smaller big task ;-)
        - something potentially useful to many Mono users (and Linux
        desktop users); and
        - we get a step closer to the real CAS :-)

>    AOT on 2.0 assemblies (at least for non-generic types)
>    Internal testing of the Web pipelines, by having mono-project.com run 
> on the Mono stack
> 
> 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.

There's no contradiction here. A lot of unfinished API, including CAS
related classes, would need to be completed, tested and audited for
Moonlight. 

We are too thin to focus on the whole Fx simultaneously, but defining a
subset (like we do today when fixing 1.x before adding 2.0 stuff) will
"shine" thru every Mono profiles.

> Anyway, I'm definitely of the mentality that if you want something done 
> in an open source project that's not getting done, you should do it 
> yourself. So I'm not trying to sound like I have expectations that all 
> of these things should somehow magically just get done.
> 
> 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.

True. Most of us works where contributions are scarce (check libgdiplus
ChangeLogs ;-)

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

This is where I somewhat disagree. First a lot of Silverlight isn't new
API, it's a subset of the existing framework. Ensuring those shared
parts are well tested (and audited :-) is good for Mono whatever status
SL achieve.

The biggest new, at least for Mono, API seems to be WPF/E. Again this is
a subset of another API. Now looking (way) back at SWF I believe having
a smaller WPF will do us more good than harm, and may decide (at a
cheaper cost) if, how and when Mono will look into WPF.

Of course my conclusions would be very different if Silverlight was Fx
4.0 (or even 3.5 ;-) and not a subset of existing stuff (that many
people already expect us to implement in the future).

> My two cents.

My personal, and canucks, 2c :)

> -- 
> - Josh Tauberer
> 
> http://razor.occams.info
> 
> "Yields falsehood when preceded by its quotation!  Yields
> falsehood when preceded by its quotation!" Achilles to
> Tortoise (in "Gödel, Escher, Bach" by Douglas Hofstadter)
> 
> 
> Miguel de Icaza wrote:
> > Hey folks,
> > 
> >     This is a repost from an internal email that really should have been
> > public. 
> > 
> > 				---- 
> > 
> >     Apologies for not sharing with the team my thoughts on Silverlight
> > as the conference was unwrapping.   I think folks found out about my
> > interest on Silverlight from Martin LaMonica's blog entry.
> > 
> >     Silverlight 1.1 is obviously very aligned with the work that we are
> > doing, and if someone is going to implement that it is a natural fit for
> > our team to do so.   For one, the majority of the work are the upgrades
> > to the 3.5 libraries (System.Core.dll, completing generics, C# 3).
> > 
> >     Today our main goal is to allow a smooth migration of developers
> > from Windows to Linux (ok, it is not smooth at all right now, you kind
> > of have to be a Unix user to do the transition at all).
> > 
> >     Silverlight brings another component into the equation: a lack of
> > Linux/Silverlight will prevent the Linux desktop from getting some
> > content.   Whether it will be a big or small issue is yet to be debated,
> > but regardless of this, it seems that Silverlight is a lot of fun to
> > implement.
> > 
> >     WPF is too big, and there is very little gain, at least in the next
> > 3-4 years, because there is no migration strategy for every ISV that has
> > invested in Winforms, so the only usage scenarios for WPF were new
> > applications, or people that were willing to throw out their investments
> > and pretty much start from scratch.
> > 
> >     On the other hand, Silverlight is a tiny subset of WPF, relatively
> > easy to implement (a weekend hack, two at most as it has been pointed
> > out by some of you) and it will be used to spice up existing web-based
> > applications as opposed to rewriting an application.
> > 
> > 
> >     Now, we have a bunch of challenges ahead of us, and it is not clear
> > when we should start work on a Mono-based Silverlight, I think we should
> > but we must:
> > 
> >         * Ship MonoDevelop 1.0, and continue improving it as we wont be
> >           a kick-ass development platform until we move beyond
> >           Makefiles and debugging with gdb and mdb on the command line.
> > 
> >           We keep saying Mono is a better development platform, but it 
> >           wont be for the unwashed massed until we get this.
> > 
> >         * Ship Windows.Forms and ASP.NET 2.0: there are hundreds of
> >           people trying to move their applications to Mono today, and
> >           we are going to need to complete both of these before we can
> >           enable the next wave of migrations.   Which is sadly the 
> >           majority of applications.
> > 
> >           (caveat: I rather have Mainsoft do Webparts that doing it 
> >           ourselves)
> >           
> >           Implicit in the above is completing the 2.0 profile, and
> >           determine what we can implement, and what we can postpone.
> > 
> >         * Visual Studio integration: we are going to have to come up
> >           with a strategy to get VS developers to deploy on Linux.
> > 
> >           A major blocker for the VS integration is that it wont be
> >           a great experience today until we finish Winforms and ASP.
> > 
> >           In a way, am ok with the lack of a Visual Studio plugin today
> >           if only because we would not look very good to Windows 
> >           developers in our current conditions.
> > 
> >           Once we finish 2.0, it would be good to have the plugin ready.
> > 
> >           Andreia started a bit of a specification here:
> > 
> >                 http://www.mono-project.com/Visual_Studio_Integration
> > 
> >           But it is a bit of a how-to.   I would want to figure out
> >           instead *what* is that we want to achieve, what kind of
> >           experience people will get, and then discuss how we get there.
> > 
> >     Considering the above, am not sure when and how we could start work
> > on Silverlight.   
> > 
> >     That being said, am obviously excited, and I have done some early
> > research on the various areas that will need work, I have posted the
> > details here:
> > 
> > 	http://www.mono-project.com/Moonlight
> > 
> >     The name was suggested by Sebastien (who also has done some research
> > that I hope he will post into that wiki page as well).
> > 
> > Miguel.
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list