[IronPython] [Code Review] "XAP-less" Silverlight application support

[Michael Foord]

Hello Jimmy,

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.

Michael


Jimmy Schementi wrote:
> (Sending this review broadly as it shows a new direction DLR Silverlight apps are taking)
>
> http://github.com/jschementi/ironruby/commit/da6b54e226adfd3a18d8ad98d618c2350ebd8351
>
> 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
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


-- 
http://www.ironpythoninaction.com/