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@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
http://www.ironpythoninaction.com/
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
