[Ironruby-core] [IronPython] [Code Review] "XAP-less" Silverlight application support
Jimmy.Schementi at microsoft.com
Tue Jul 21 07:21:51 EDT 2009
You just had to ask now =P ... I was going to blog about this more extensively tomorrow, but here's a preview of my thinking about this:
My motivation behind xap-less is to make DLR Silverlight apps less complex, and more like how the web works. This change is just an experiment in that direction, and I'm very open to any opinions folks have about this.
First things first though, this change make xap-less completely opt-in ... you have to use the "downloadScripts=true" InitParams setting to enable it. Without this param it will behave as it used to. Also, even with this setting it will not download the file if it exists in the XAP. I was very conservative about this change, as I'm just playing around with some ideas.
Also, even if xap-less becomes the default, I'd make sure existing deployments did not break; in the xap will always be an option for deployment (and quite possibly the preferred way), but I want to get back to the place where we didn't need a XAP file and didn't need Chiron for development.
<!-- index.html -->
document.message.innerHTML = "Hello, World!"
Very simple and clean. No need to start a web-server or install Mono on the Mac just to make a client-side page. The JS file hosts Silverlight, and then Microsoft.Scripting.Silverlight scans the HTML page looking for <script> tags, executing them as they are encountered. Pre-packaged xap files are there so a basic app would never need to touch the XAP. There is a project being released today on http://visitmix.com/Lab which implements SL Ruby and Python apps just like this, with the intention that the ideas about making things simpler are merged back into Microsoft.Scripting.Silverlight. I'll send out links when it's live, but hopefully you'll just hear about it. =)
FWIW, I'd leave the "entryPoint" activation in there as well, so only if you didn't set entryPoint OR didn't have a valid entry point in the XAP then we'd look at the HTML page for <script> tags ... we can deprecate it if enough people stop using entryPoint. Also, it's a little strange to take a bunch of python islands and assume it's one module. Should those islands be their own modules? Also, I know there might be some standards issues with doing a <script type=""> when it's not a list of approved types. We'll have to make sure this is done in a standards-compliant way, as I'd love to see browsers support this out of the box (ha, yeah, sounds crazy I know), and this work should be a stepping stone to that. I've already reviewed the visitmix.com/Lab project and there are some standards issues that I'll blog about tomorrow, so please don't get caught up on a prototype or proposal, just imagine what things could be like. =P
This scales to bringing in other files too, as you can use <script type="application/python" src="foo.py" />. Microsoft.Scripting.Silverlight would scan the HTML file for <script> tags with the src attribute, and download the files ahead of time. But what happens if those files "import" something? The visitmix project I was referring to does not handle this case, since it's just a prototype of how browsers could support multiple languages. But we'd need to support this. And this is where it could look back the XAP. So if we ever did take away entryPoint then you'd activate your apps by just doing this:
WRT sharing IronPython assemblies between apps, that change was kinda silently checked in around SL3 RTW since I wanted to test things a bit more, and find a place to host the packages. Documentation will pop up on the IronPython codeplex site in a few weeks about how this all works. And the way you host your apps should still be caching it, but you'll see a download request (in Firebug for example). Are you sure they are being fully downloaded each time? Maybe the AppManifest.xaml downloading is forcing a download each time, but I remember it going to the browser cache.
From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] on behalf of Michael Foord [fuzzyman at voidspace.org.uk]
Sent: Tuesday, July 21, 2009 2:37 AM
To: Discussion of IronPython
Cc: ironruby-core at rubyforge.org
Subject: Re: [IronPython] [Code Review] "XAP-less" Silverlight application support
Will xap-less be an 'alternative' deployment scenario for dynamic
silverlight applications or the 'new and only' deployment scenario?
If it becomes the 'right' way to do it please realise that you are in
one swoop obsoleting all the articles, tutorials, examples (and books)
on developing Silverlight applications with IronPython / IronRuby. There
better be a big payoff for such a hugely backwards incompatible move...
When the move to xap files happened we were told this was a big win for
dynamic languages as all needed Python (or Ruby) files would be
downloaded compressed - and this was *much* faster than downloading them
synchronously on import (as the integration in Silverlight 1.1
originally did). What is the motivation for the change?
Does this change allow the IronPython assemblies to be shared between
applications (and cached)? I realise this can be done already (I use it
with my examples) - but I still see the IronPython assemblies being
re-downloaded every time you refresh the page or go to a new example,
even though they are from the same location.
Jimmy Schementi wrote:
> (Sending this review broadly as it shows a new direction DLR Silverlight apps are taking)
> Beginnings of "XAP-less" Silverlight application support. Note: Silverlight apps are *required* to have a XAP file, but with this change it can get down to just a container for the AppManifest.xaml file. Python/Ruby would ship with a single XAP file pointing to the .slvx files for a given release.
> Adds a "downloadScripts" initParam to indicate whether paths to script files and XAML files should be resolved to the web-server (relative to the XAP), if the file is not found in the XAP. Also adds "downloadScriptsFrom" to customize what path they are based off of. Because of the opt-in nature of this change, existing DLR Silverlight apps should not break.
> Files are downloaded synchronously as code runs, by having the PlatformAdaptationLayer use a new BrowserVirtualFilesystem: HttpVirtualFilesystem. So when a language's include mechanism is used (require , load, import, etc), it will download the file by using XmlHttpRequest in synchronous mode. It will also cache each downloaded file's contents, so a file will only be downloaded once, even if it is included multiple times. Note: future work will hopefully allow asynchronous includes, so this can be production-ready. For now, it should only be used for development.
> Note: this change decreases the need for Chiron significantly. In this mode, Chiron only creates a XAP file with the necessary assemblies and AppManifest.xaml, if it doesn't exist already. One could imagine providing a XAP file for each language, and then Chiron wouldn't be needed for development. However, for using the latest language assemblies, and auto-detection of languages used, it's still useful for development. So some changes have been made to Chiron to support this better:
> A "localApplicationRoot" appSetting has been added to Chiron to adjust where it looks for script files (when determining what languages are used). This allows you to make sure Chiron is looking in the same place your application is downloading scripts or xaml from, so it can still generate a correct XAP file for you. "application/ruby" and "application/python" mime-types have been also added to Chiron also to enable downloading of those script files.
> All of Chiron's appSettings are now override-able as command-line switches: /u[rlPrefix], /e[xtUrlPrefix], /l[ocalAppRoot]
> Run Merlin/Main/Hosts/SilverLight/Tests/tests/manual/test_foox/run.bat for an example of how this works (it requires a Silverlight Debug build, so if you run Merlin/Main/Languages/Ruby/Scripts/Dev.bat, just run "bsd" and that will *b*uild *s*ilverlight in *d*ebug mode)
> Adds a stub for similar support through IsolatedStorage, but that will come later.
> Also tweaks the DynamicEngine.CreateRuntimeSetup method to better support other DLR-hosts in Silverlight (http://lists.ironpython.com/pipermail/users-ironpython.com/2009-July/010780.html).
> Users mailing list
> Users at lists.ironpython.com
Users mailing list
Users at lists.ironpython.com
More information about the Ironruby-core