[Mono-dev] Silverlight early implementation thoughts.

Miguel de Icaza miguel at novell.com
Sun May 6 10:40:51 EDT 2007 

Hello,

     On this thread, there is one last thing I wanted to mention: 

     Silverlight has opened the doors to a fresh influx of new
developers that do not necessarily care or are interested about our
other goals.

     And this is a project interesting enough that it will likely make
Mono more exciting to hack on for a few people.
    
Miguel.

> 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.
> 
> 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.
> 
> 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)
> 
> (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
>    Was CAS ever finished?
>    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.
> 
> 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.
> 
> 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.
> 
> -- 
> - 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

More information about the Mono-devel-list mailing list