[Mono-dev] Silverlight early implementation thoughts.

[Jonathan Pryor]

On Sat, 2007-05-05 at 18:09 -0400, Joshua Tauberer wrote:
> Miguel wrote:
>  >     Silverlight brings another component into the equation:
>
> IMO, the Mono community/project tends to spread itself very thin. Lots 
> of things get started but not polished up and finished very well.

For the most part, agreed -- there's just too much that fits within the
current Mono umbrella and not enough resources (paid Novell developers
and contributors combined) to cover them all.  I'm not entirely sure
that this is a bad thing per-se, it just requires that we prioritize
things appropriately.

<snip/>

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

The thing to keep in mind is that the "entirely new API" is fairly
minimal here.  Most of it is a trimmed down .NET 2.0 API + Linq -- most
of which we already have or need to do anyway.  The new API portions are
fairly minimal in the grand scheme of things -- we already have the JIT,
GC, 90%+ of the needed class libraries (or more).

So what this mostly amounts to is a new use of existing code, which can
lead to additional polish/completion of existing APIs that need to be
done anyway (i.e. add missing .NET 2.0 methods), which can only be a
good thing.  (There's also the question of how best to create the
stripped down v2.1.0.0 assemblies, and one of the suggestions is to use
Cecil to write a subset generator, which can result in only more polish
to Cecil and similar libraries.  It's all good. :-)

The implementation of new API and a browser plugin may be a diversion of
resources, but it's a diversion that will mostly add polish (and users)
to what we already have.  From this perspective, how can we NOT do it?

:-)

 - Jon