"…mais ce serait peut-être l'une des plus grandes opportunités manquées de notre époque si le logiciel libre ne libérait rien d'autre que du code…"

Silverlight and the DLR

Posted by patrick sur mai 4, 2007

Quelques extraits intéressants tirés de Ted Leung (http://www.sauria.com/blog/2007/05/01/silverlight-and-the-dlr/) sur Silverlight (WPF/E)



Silverlight and the DLR

Microsoft has announced that it is embedding a version of the CLR into their Silverlight RIA technology. The CLR enabled version of Silverlight will run inside Firefox (both on Windows and OS X) and inside Safari. This is a good step at cross platform support, but the omission of Linux, while not surprising, reduces the reach of Silverlight versus Flash or regular AJAX.

The most interesting part of the whole business is the Dynamic Language Runtime, which is the project that Jim Huginin has been working on since he arrived at Microsoft. The DLR currently supports JavaScript, a dynamic version of Visual Basic, IronPython, and IronRuby. John Lam’s work at Microsoft also appears to be paying off. eWeek had three good articles on DLR technology, and all three articles include conversations with Jim and John. It’s nice / interesting to see that two people could have a large impact on Microsoft. The DLR is being made available under a BSD style license. While I have to give props to Microsoft for choosing an unrestrictive license, I’d point out that a license is not a governance system, and while the DLR might technically be open source, the “Core CLR” definitely is not, and neither is the XAML portion of the Silverlight runtime — no surprise there. I wonder if we will be seeing a port of the DLR on top of Mono. I also wonder if IronRuby can run Rails, although that seems like a weird thing to want to do inside of Silverlight.

Another part which I find interesting is the inclusion of Linq as part of the Core CLR. I like Linq, and if Microsoft is going to try to define a new platform for inside the browser, I’m happy that they’re including Linq as part of the core.


The inclusion of facilities like Linq will boost the semantic level of the platform running in the browser. Granted, it only does that for Silverlight, but I hope that this puts some pressure on the other players to provide more leverage in the platform. If we are going to be building much richer applications inside the browser, we are going to need all the help that we can get.

So what?
In the end, though, I probably won’t be doing much with Silverlight, for the same reasons that I’ve written about before. The technology has definitely gotten stronger, but the other issues haven’t really changed much: there are no tools for the Mac or Linux, and as far as influencing the technology, you’re just standing outside the Big House, pressing your nose up against the window.


Une autre réaction de Miguel de Icaza (http://tirania.org/blog/archive/2007/May-03-1.html)


Silverlight and WPF

Today Microsoft announced two Silverlight editions: one that went into beta (Silverlight 1.0) and is a relatively simple technology.

Silverlight 1.0 uses a retained graphics system (a canvas) that exposes the internal structure to the browser DOM. It has no scripting capabilities built into it, all the scripting support is actually done by the Javascript interpreter in the browser and all changes are done by talking to a Javascript object exposed by the hosted Silverlight surface.

The scene definition is done using the XAML markup using a subset of the WPF primitives available in the full-blown WPF. Then the big announcement came: The second edition was Silverlight 1.1, and this one is a different beast altogether. 1.1 extends the model by embedding a complete Common Language Runtime

There are a handful of changes to the runtime. Here are some notes on what I found out about it today. It might not be complete nor accurate:

  • A new security system: Unlike the CAS there is no stalk walking but instead there are trusted and untrusted assemblies. This is part of a new sandboxing model.
  • Trusted assemblies have a way of flagging entry points as being untrusted. which requires that the caller be a trusted assembly.This means that calling things like FileStream File.Open (string filename) from an untrusted assembly is not permitted.

    Instead developers would call something like FileStream File.OpenDialog(...) (which is hosted in a trusted assembly) and this would in turn call File.Open(string) and this would return a FileStream that the user selected with a dialog box.

  • The API has been trimmed down: some classes were removed that did not make much sense for the core.
  • A Minimalist WPF implementation: this is now available as a new assembly. This implementation at this point does not seem to have support for high-level controls like Buttons or Sliders, those have to be authored in a per-application basis.There is talk about which pieces belong in the minimal WPF and which pieces do not.

    In my opinion, keeping the controls out was a good idea as the controls in the real WPF are a bit too big.

  • Dynamic Language Runtime: the dynamic language runtime is an integral part of the Silverlight distribution.

Dynamic Language Runtime


The Dynamic Language Runtime was announced today. Jim Hugunin’s blog has the details and rumor is that in the next couple of days/weeks he will be posting on his blogs the technical details behind the design of the DLR.

Binaries of the DLR were released today as part of Silverlight 1.1, and the source code was included with IronPython 2.0 (also released today).

The release for the DLR is done under the terms of the Microsoft Permissive License (MsPL) which is by all means an open source license. This means that we can use and distribute the DLR as part of Mono without having to build it from scratch. A brilliant move by Microsoft.

During the keynote they announced support for four dynamic languages built on top of the DLR: Python, JavaScript (ECMAScript 3.0), Visual Basic and Ruby.

The rumor on the halls is that IronPython and Ruby will be released under the MsPL license, while ECMAscript and Visual Basic will continue to be proprietary. From Jim’s announcement:

For the short term, our focus is on using a small number of languages to drive the first wave of DLR development where we can work closely and face-to-face with the developers in order to iron out the worst kinks in the DLR design. After this initial phase, we want to reach out to the broader language community. If you’re building a language on top of .NET and are interested in supporting dynamic language features then we want your feedback on the DLR. However, I’d discourage you from trying to implement on top of the DLR today. I don’t want you to get frustrated trying to work with these really early bits and then not be interested in working with us when we’re better prepared to engage with the language community. We plan to kick off a broader engagement with language implementers at the upcoming lang.net conference in three months – at the end of July. This will be the best place to really engage with the DLR and let us know what we got wrong.

Mono and Silverlight

For a long time a common question to the Mono team was when we were planning on implementing WPF.

Most people want to hear a date like « tomorrow », « next month », « in a year ». But the answer is more complex than just thinking « we can do this in N months ».

We as a team have to evaluate the cost of implementing a technology and contrast it with the impact that such technology would have. With our finite development resources (in the Mono community and the companies contributing to it) we have to pick our battles.

And implementing WPF was never really high up on the priority list for a couple of reasons:

  • WPF requires a very big investment before things will start working.
  • Users of WPF is limited to those starting new applications and are willing to start those applications using WPF.
  • Only a minority of existing users (Windows.Forms) were willing to rewrite their software to move it to WPF. The rest basically will continue developing Windows.Forms and using the technologies they have been using for the time being.

So it is fair to say that we currently do not have plans to look at WPF.

But a Mono-based Silverlight is an entirely different story. Unlike WPF that requires people to rewrite their software to take advantage of it, Silverlight is aimed at the Web and it will become a nice complement, a way of spicing up existing web applications without rewriting what already works.

It makes tons of sense for us to start looking at an implementation of Silverlight on Linux with Mono. There is already a XAML loader, it is the perfect excuse to use Antigrain for high-speed graphics and that only leaves the pesky media issue to be solved.

In fact, am kind of happy that Microsoft did not do the port themselves as implementing this sounds incredibly fun and interesting.


Sur le blog de Jim Hugunin (http://blogs.msdn.com/hugunin/archive/2007/04/30/a-dynamic-language-runtime-dlr.aspx)


Today, at MIX 07, we announced a new level of support for dynamic languages on .NET that we’re calling the DLR.

From the beginning, Microsoft’s .NET framework was designed to support a broad range of different programming languages on a Common Language Runtime (CLR).  The CLR provides shared services to these languages ranging from a world-class GC and JIT to a sandboxed security model to tools integration for debugging and profiling.  Sharing these features has two huge benefits for languages on the CLR.  First, it’s easier to implement a language because lots of difficult engineering work is already done for you.  Second, and more importantly, these languages can seamlessly work together and share libraries and frameworks so that each language can build on the work of the others.

The CLR has good support for dynamic languages today.  IronPython-1.0 demonstrates this.  The new Dynamic Language Runtime (DLR) adds a small set of key features to the CLR to make it dramatically better.  It adds to the platform a set of services designed explicitly for the needs of dynamic languages.  These include a shared dynamic type system, standard hosting model and support to make it easy to generate fast dynamic code.  With these additional features it becomes dramatically easier to build high-quality dynamic language implementations on .NET.  More importantly, these features enable all of the dynamic languages which use the DLR to freely share code with other dynamic languages as well as with the existing powerful static languages on the platform such as VB.NET and C#.

The DLR is about giving you the best experience for your language – true to the language, excellent tools, performance and seamless integration with a wealth of libraries and platforms. The essential benefits of the DLR are about sharing. It lets language implementers share standard features rather than rebuilding them from scratch. This lets them focus on the features that make a given language unique rather than on reinventing yet another GC system. It lets developers share code regardless of the language the code is implemented in and to use whatever language they prefer regardless of the language preferred by the environment they want to run in. Coupled with the Silverlight 1.1 platform announced today, it even lets languages share a sandboxed security model and browser integration.  This means that developers building browser-based applications can now use their preferred language even for client-side code.

We’re initially building four languages on top of the DLR – Python, JavaScript (EcmaScript 3.0), Visual Basic and Ruby. We shipped today both Python and JavaScript as part of the Silverlight 1.1alpha1 release today. John Lam and I will be demoing all four languages, including VB and Ruby, working together during our talk tomorrow at 11:45.

In addition to the Silverlight release, we’ve also made the full source code for both IronPython and all of the new DLR platform code available on codeplex under the BSD-style Microsoft Permissive License. All of that code can be downloaded today as part of the IronPython project at codeplex.com/ironpython. If you want to know more about the DLR, you should feel free to download the code.  However, you should understand that this is a very early release of these bits and we still have significant work left to do including refactoring, design changes, performance tuning – not to mention documentation


Sur Voidspace : http://www.voidspace.org.uk/python/weblog/index.xml


Silverlight: Python in the Browser

scanner Ok, so after a couple of days digesting it, the new Microsoft announcement is really big news. Everyone is talking about it, well, everyone except the Python community [1]. Smile

There are two important aspects, and Microsoft chose to announce them at the same time.

  1. IronPython 2.0 is built on top of a new layer called the ‘DLR’, the Dynamic Language Runtime. This abstracts a lot of the useful elements from IronPython 1.0 into a dynamic type system and hosting environment for dynamic languages. The DLR is Open Source, and on top of it Microsoft are developing four languages:

    • IronPython
    • IronRuby
    • A dynamic version of VB
    • Javascript

    The DLR is shipped with the IronPython 2.0 distribution. IronRuby is not yet available [2], but an alpha ought to be available this week. It doesn’t yet run Rails, but it will eventually. Through the DLR, dynamic languages should be able to share libraries and use each other’s objects…

  2. SilverLight 1.1 ships with a customized version of the CLR: the .NET ‘Common Language Runtime’. This only contains trusted assemblies, so applications running in it are sandboxed. The exciting part, is that the DLR runs on top of it! So you can now do rich client programming for web-apps, with full access to the browser DOM (plus the Silverlight capabilities) using IronPython or IronRuby. This is big news [3]. You also have the .NET libraries, including WPF/E which is the browser side equivalent of Microsoft’s new user interface library. Microsoft are touting the media-streaming capabilities of Silverlight and I have no idea what other goodies are lurking inside it for building applications, yet…

Silverlight is cross-platform and cross-browser, well partly anyway [4]. Smile

The bad news is that the DLR doesn’t yet compile and run on Mono. This should just be a case of fixing compiler bugs, and possibly implementing a few more classes and methods. Seo Sanghyeon has already made some progress on this, and based on past experience it won’t take him very long.

Additionally, there is no Silverlight client for Linux. However, Miguel de Icaza, the project lead for Mono, is very excited about implementing the Silverlight CLR; much more excited than he is about implementing WPF for the desktop which he thinks will see very slow developer uptake.

So what can you do with Silverlight? Well, up to now I’ve only got as far as running the demos. You’ll need Silverlight 1.1 Alpha installed and the Silverlight 1.1 SDK for the first set of demos.

If you want to try it with Firefox you’ll also need an HTTP server (I use CGIHTTPServerWithSSI which works fine, just drop it into the samples directory). I’ve had some of the demos working on Windows. Andrzej Krzywda tried it with Firefox on the Mac and Firefox kept crashing..


Personally I find the idea of being able to write rich client-side web applications with Python very exciting, but the responses from other developers I’ve talked to have been much more lukewarm. Comments include, ‘it sounds like Java applets from 1995’, ‘I don’t like Microsoft tools’, ‘it means installing another runtime’, ‘I like Javascript’ and so on… Other commenters cite the lack of development tools for the Mac and Linux. If Silverlight is just an alternative to Flash then I guess this is an issue, but I’ve never done any flash development. Personally, a Python IDE is the development platform I want – and there are plenty of those.



Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )


Connexion à %s

%d blogueurs aiment cette page :