Geeks With Blogs

News




What I do:

Identity Mine

MVVM Light

GalaSoft


What I am:

Microsoft Most Valuable Professional, Client Application Development

Microsoft Certified Technology Specialist, Windows Presentation Foundation

WPF disciples


Social:


View my profile on LinkedIn

XING
Creative Commons License
Diary of a Code Trotter by Laurent Bugnion is licensed under a Creative Commons Attribution 3.0 Unported License

All source code on this blog is licensed under the MIT license.

Copyright (c) 2006 - 2011 GalaSoft Laurent Bugnion

Laurent Bugnion (GalaSoft) Diary of a Code Trotter
I received today the confirmation to my registration for MIX07 in Las Vegas. I am very excited to go and attend this event again. Last year's MIX06 has been a defining event for me, followed by intensive work to introduce WPF into my firm. So far this activity was a success, and I am very excited to see the "real" development activities starting (as oppposed to prototyping, which we did most of last year).
This year's MIX07's major technology is probably going to be WPF/E. While we don't plan to use this for our web application (rather XBAPs), I am hoping that some of the WPF/E features will slowly (well, not too slowly) make it into XBAPs too. For example, wouldn't it be nice to have an XBAP able to communicate with the web browser DOM and with the script engine? Of course, multi-platform support would be excellent too (XBAPs are only supported on IE on Windows XP, 2003 server and Vista).
Why not offer the following hierarchy (Number 1 has the most impact on the target system, number 4 has the least):
  1. Standalone WPF application installed with MSI for usage without any restriction.
  2. Standalone WPF application installed with ClickOnce for usage without restriction (but with ClickOnce limitations, i.e. installation per-user, no registry changes, etc...).
  3. XBAP for full .NET support (including WPF 3D, whole .NET framework support, etc...). This version would run in the sandbox, of course, but with less limitations than today).
  4. WPF/E for limited .NET support but maximum flexibility (including perfect integration in existing web pages).
By allowing an XBAP to communicate with the JavaScript engine, it would enable IFRAME-hosted XBAPs to "talk" to the rest of the "hosting" page!
This hierarchy would have the advantage of offering seamless scalability to the developer. Today, XBAPs don't really fit with the rest of the offering. On one hand, the sandbox restrictions put XBAPs too far from the standalone applications. On the other hand, the lack of integration with the web browser's engines and the lack of multi-platform support make that XBAPs cannot really be qualified as web applications. I think that my proposal would let XBAPs fit better in the whole WPF landscape, and would offer a huge added value to software developers.
Anyway, I am sure that MIX07 is going to be very exciting and I can't wait to be back in Vegas! See you there?
Posted on Thursday, January 18, 2007 1:41 PM Technical stuff , .NET , WPF | Back to top


Comments on this post: WPF scalability wishes / MIX07

# re: WPF scalability wishes / MIX07
Requesting Gravatar...
You raise some moot points. In terms of ClickOnce, it would be useful if multiple folders could be deployed. In terms of XBAPs, they need to be able to communicate with the HTML layer so search phrases can be exposed. I would like to see XBAPs talk to the rest of the hosting page via C# and not just JavaScript - maybe via the WPF/e runtime if ever we get one?! Can't understand why a C# runtime is not an integral part of IE anyway - I really want to get away from all this JavaScript stuff. Maybe it will be possible to embed XBAPs in ASP.NET? I also think many of the XBAP security limitations negate a lot of the Windows RIA philosophy. If it's sandboxed what would be wrong with dialogs, drag and drop? XBAPs are surely the way forward particularly as the Windows OS is the predominant browser and this has got to be the best way to reach untrusted parties with a powerful UI.
Left by Rod Mac on Mar 11, 2007 8:24 PM

# re: WPF scalability wishes / MIX07
Requesting Gravatar...
I am not sure which one of the points I raise you think is moot. What you're saying is pretty much what I am saying too (communication with the HTML DOM for example, or reducing the sandbox' limitations), except that instead of JavaScript, you'd prefer a C# engine on the client. For me, I'd prefer XBAPs to communicate with JavaScript and additional effort to be put in porting the runtime to other platforms.

JavaScript on the client doesn't bother me. It's just another programming language (and one I appreciate anyway).

Note also that both of us will be happy. WPF/E should bring C# to the client sometimes, and XBAPs will probably be able to communicate with the hosting browser soon.

Finally, some of the security limitations are not due to security, but weren't implemented because of a lack of resource, so we should see a better implementation in WPF V2.

Laurent
PS: Since ASP.NET runs on the server, I am not sure how you want to have XBAPs run in that... you can already make a server-side control adding an XBAP (in an IFRAME) to a given page, with the mentioned limitations.
Left by Laurent on Mar 11, 2007 8:58 PM

# re: WPF scalability wishes / MIX07
Requesting Gravatar...
The moot points were numbered 1-4!
As you succinctly put it in your latest post, the 2 requirements are HTML DOM communication AND reducing sandbox limitations. I wouldn't decry the need for JavaScript comms, I just personally dislike JavaScript having built a tree control from scratch - an area where you can't beat compiled code for performance. Having built an XBAP in C#, it seems a bit of a hassle not being able to go all the way (strictly Win-Win) save for getting an XBAP listed in Google so it might be found.
My point about embedding an XBAP in ASP.NET is that it would be nice to have all the UI logic running as an XBAP on the client - written 100% in C# - with the business logic/data layer running (of course) on the server. Perhaps it might not make sense but could the UI be streamed out to a WPF/e equivalent of Flash?
What bothers me when you say we should both be happy with 'release 1.0' is my feeling is that MS need to do more for Orcas RTM because Adobe are going to effect considerable pressure on the MS developer community with the release of CS3. There is not a single day that goes by here where I am fighting Flash and Acrobat efforts from the (MAC) design and print world. That is why I would like to see strong C# support from the outset and the features you so rightly point out.
Thank you for the interesting post - I don't disagree with anything you say!
Left by Rod Mac on Mar 13, 2007 12:41 AM

# re: WPF scalability wishes / MIX07
Requesting Gravatar...
P.S. Apologies if I have been slow on the uptake - you're talking about client side scripting on the surface of the XBAP, I'm talking about the less efficient route of making the XBAP/HTML layers talk via server side calls. I thought the IFRAME thing wouldn't work at all - have just discovered a weird issue on my machine following a corruption of my user profile (ironically following a hardware upgrade to better support WPF) and I'm blowed if I can get an XBAP (and now loose XAML) to run at all unless compiled on this machine. Nasty unauthorized access issue and it wont go away. I still want C# everywhere to beat off Adobe though!
Left by Rod Mac on Mar 13, 2007 1:29 AM

# re: WPF scalability wishes / MIX07
Requesting Gravatar...
Now it's my turn for apologizing for being slow - I was badly sick last week but I am better now.

Your use of the word "moot" confused me slightly. To me, it means that the points made are obsolete, but you end up by saying that you don't disagree with them, so let's just forget that.

I think we agree on the 2 main needs (DOM interaction between HTML and XAML, and reduce the sandbox' limitations). The first thing (DOM interaction) could be done using the same model as Java applets use (LiveConnect): In one direction, JavaScript can access the applet's inner members, and in the other, Java may call JavaScript functions, and thus can access any object (more or less) that JavaScript can get.

Finally a correction: I didn't say we *should* be happy, I said we *will* be happy: The versions to come of WPF/E and WPF will probably implement some of the changes we discussed here.

Greetings,
Laurent
Left by Laurent on Mar 19, 2007 8:40 PM

Comments have been closed on this topic.
Copyright © Laurent Bugnion | Powered by: GeeksWithBlogs.net