XAML: Yet another language for plug-ins security...
I've been looking at XAML and I have to say, it is just another language for plug-ins to make heavy use of, but also another language for plug-ins to have to secure. Let's look at the different things XAML can do today that might not be cool from a plug-in standpoint and then see if there are any features that might help eliminate these security concerns.
1. Today, in Avalon, all of the controls lack security attributes. This means that any XAML code that is created could easily pop any type of UI it wanted without the security subsystem disabling access to anything you can think of. This will most likely be fixed in later versions I'm hoping, because a plug-in that is supposed to be rendering an icon of itself, actually rendering a pop-up is pretty darn annoying.
2. When you write XAML code you can render just about any element you'd like, along with including any code elements directly. I'd like to see XAML changed so that during the compilation step I can disable certain constructs and have them parsed out (especially code elements), and maybe even limit the subset of available types the XAML code can use. Interestingly enough the serialization team for .NET came up with a great solution for this called a binder. Whenever stuff is deserialized on the other end of the pipe, every type being instantiated can be remapped to a compatible type or an exception can be thrown to stop the deserialization process. This type of control over the compilation might be nice as well. Since XAML is XML you can do this anyway with a simple processor just for your code.
3. I think that Longhorn probably has the ability to do pre-render timing estimates for any XAML as it compiles into code (this would be for run-time parsed XAML, not for pre-compiled XAML shipped with the app. This is a feature that needs to be implemented at the target machine, just like IL is JIT'ed at the target machine). Currently, if you need to figure out an approximate time to render a particular element you'd have to investigate the machine and then process the XAML yourself to get an approximate time. Being as Longhorn is constantly rendering elements of all types it knows more about the rendering process and how long it will take than you could probably glean. You can time an element by rendering it on another thread and shutting it down if it takes too long, but again, this is a plug-in framework having to write additional security code for a new language.
I have to say XAML is an old concept. Writing XML that is then translated into code/drawing primitives for display on the screen? I remember doing this when MS first came out with their MSXML Tech Preview. We generated an Excel spreadsheet defining a view in a real-estate application, exported this view into XML, and then used XSLT (this was our compiler) to generate a bunch of different types of code so the views were available on different platforms. Our primary outputs were DHTML for a stand-alone client (the VB DHTML Application option, boy was that a long time ago), and HTML for our own web site. However, I also had outputs for VB Form language to try and get rid of the DHTML application eventually, and C++ Dialog code to create dialogs (at this time, the only GUI for C++ was to create dialogs so it made sense to output dialog code because you could actually view the output in Visual Studio). Of course all of the security concerns were just as valid when I was writing this code. We had to make sure the compiler I was writing was only outputting good code that wasn't going to cause a security concern. Since XAML is a general purpose compiler, we either need cool tools to pre-process, or hooks to process at compile time.