[Mono-dev] Silverlight early implementation thoughts.
jit at occams.info
Sat May 5 18:09:28 EDT 2007
> Silverlight brings another component into the equation:
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
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
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
"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
> 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
> 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
> 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:
> 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:
> The name was suggested by Sebastien (who also has done some research
> that I hope he will post into that wiki page as well).
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list