________________________________________
From: Jimmy Schementi
Sent: Tuesday, July 21, 2009 4:21 AM
To: Discussion of IronPython
Cc: ironruby-c...@rubyforge.org
Subject: RE: [IronPython] [Code Review] "XAP-less" Silverlight application
support
Michael,
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.
Eh, I know that was the messaging around XAP files being compressed and faster for
download times, but that's because they were synchronously downloaded and the browser can
only handle one of those at once. If you use gzip-compression on your web-server and
download each file asynchronously, I don't think you'll see much of a difference.
However, "minifying" Ruby or Python like most JavaScript is really not
possible, so people could always opt for a XAP file. But I really want to give back the
text-only experience, even for deployment. There are still good ways to support
asynchronous downloading of files that get imported (I'll talk about that below), so we
should still explore those ... especially since this is the way browsers work today.
Imagine if Ruby and Python in the browser felt not that much different than
JavaScript, but allow for other deployment options if the app needs it. For
example, a Python Silverlight Hello World app should just be this:
<!-- index.html -->
<script type="text/javascript" src="silverlight-dlr.js"></script>
<div id="message"></div>
<script type="application/python">
document.message.innerHTML = "Hello, World!"
</script>
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:
<script type="application/python">
import app
</script>
If an import failed against the XAP, it could look on the web-server. Though today's
implementation is synchronous, that needs to change. So the guidance would be to
either to put those files in the XAP, or allow the app-author to specify their
dependencies up-front (like JavaScript does, it could even be with <script>
tags also) so those files could be downloaded and import would just run the contents
of the pre-downloaded files. Unfortunately, even if we could do import asynchronously
(by making import/require/etc continuation-aware), the downloads would still happen
one at a time, which is unacceptable for deployment. So it's either the up-front-list
or in the XAP.
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.
I know that was kinda long winded, but I'm pretty happy about fixing a lot of the
ugliness we had to add from SL1.1 to SL2, while keeping the deployment benefits SL2
had, even if they are in a different form. Today's model is too complicated for
people coming from JavaScript to get started, so lowering the bar to the
<script> tag level may get the attention of more developers. Let me know if
anyone has more questions about this.
~js
________________________________________
From: users-boun...@lists.ironpython.com [users-boun...@lists.ironpython.com]
on behalf of Michael Foord [fuzzy...@voidspace.org.uk]
Sent: Tuesday, July 21, 2009 2:37 AM
To: Discussion of IronPython
Cc: ironruby-c...@rubyforge.org
Subject: Re: [IronPython] [Code Review] "XAP-less" Silverlight application
support
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
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
