[Mono-dev] Mono's Silverlight update.

[Miguel de Icaza]

Hey folks,

    In the last few days we have been doing a little bit of research
on what is needed to complete SIlverlight.   The major sticking point
is deciding on a rendering engine and currently some people are
testing Antigrain, Cairo and GDI+ to get an idea of the performance of
these libraries as well as looking at our options when it comes to
media decoding and playback.

    We have tried to keep the status on the Moonlight page up-to-date
on the Mono site, so you might want to read either the diffs, or read
the actual page every once in a while.    Some of my rough notes as I
go around Silverlight can be found on the /WPFNotes page in the mono
wiki (I should probably move them here though).

    The class hierarchy for instance (on the WPFNotes page) looks
fairly simple, there are two kinds of classes there: those that derive
from DependencyObject, and those that do not.   The ones that derive
from DependencyObject participate in the whole notification/
propagation system and the others do not.

    It is probably simple for those that want to contribute to start
work on the classes that do not derive from DependencyObject.  We
should follow the regular process: write nunit test cases to
understand the API, and then write the API.

    One thing that seems clear to me is that the rendering should be
done in the unmanaged world.  Just like the full WPF does, it seems
like the managed code is merely a front-end that communicates with the
backend and creates the object in the unmanaged world.  The unmanaged
world actually does all the rendering.  There are a couple of
questions as to how much needs to go in the unmanaged world, but at
least it is clear that anything that derives from Visual as well as
the majority of the things references from them (Brushes and
Transforms at least, and maybe also PathSegments?)

    I have stubbed out some classes in olive/class/agclr, but have not
really done any of the real work in there, just something to get to
understand how these pieces fit together.

    So we currently have a few areas that must be worked on that can
be started without finalizing the rendering research or that require
changes to the JIT (the security system):

    * Non-DependencyObject classes in agclr assembly.
    * System.ServiceModel.Web

    In addition to those two,  I should be able to post next week the
status pages for the various class libraries that are part of
Silverlight, so we get a better understanding of what we might be
missing in mscorlib, System and a handful of others.

    A bit of a problem with the classes in agcore is that there is no
Silverlight documentation for them, you must extrapolate from the .NET
3.0 documentation to make some sense of them.  They are slightly
different and contains fewer base classes, fewer abstractions and a
very limited set of exposed methods and properties if you compare them
to the 3.0 stuff.   Implementation of these should be based only on
the public methods shown by the Object Browser in Visual Studio or the
output of monop2 -d -r:agcore.dll TYPENAME.

    System.ServiceModel.Web.dll is not part of Silverlight 1.1 as
shipped I think, but many of its components are on the Silverlight
poster as technologies that will be part of the final product, in
particular it is worthy to note the following namespaces in this
assembly (you need the Orcas beta to get the documentation for it):

    * System.ServiceModel.Syndication (Atom, RSS support)
    * System.Xml (Json reader/writer), some helper code is in other
places in the same assembly

    These are fully documented in Orcas, and can be tested/developed
in advance, you will need to download Orcas though to read the
docs.

    When writing code, please make sure that you follow the
conventions and policies in:

        http://www.mono-project.com/Contributing
        http://www.mono-project.com/CodingStyle

    In particular, never, ever, absolutely never decompile or
disassemble Microsoft assemblies.  If you need to figure something
out, figure it out with test cases, which have the dual advantage of
becoming a regression test suite that help us avoid regressions and it
helps programmers understand how things work.

Miguel.