[IronPython] Developing Silverlight apps using IronPython -- best strategies

[Michael Foord]

On 02/07/2010 19:34, Jimmy Schementi wrote:
> [snip...]
>> 1) What is the cutting-edge way to deploy an SL4/IP2.6 application?
>> I've basically seen two:
>>       - The "all-in-xap-way", with the python application and assemblies as well
>> as the XAML in the xap file, as it is described in the article series at
>> http://www.voidspace.org.uk/ironpython/silverlight/silverlight_application.s
>> html
>>       - The "Gestalt way", with some magic inside, allowing to place
>> XAML/Python code directly in the HTML Is the first way out-of-date? Are
>> there more techniques? What are advantages/disadvantages?
>>      
> There are two ways of developing apps because the Silverlight application model and the HTML application model are way different. The all-in-xap-way doesn't fight Silverlight at all, but it is a fight against how you're use to making web-apps. The script-tag way doesn't fight the web at all, but requires some tricks to work in Silverlight's world (zip files for DLL's, for example).
>
> We now advertise the script-tag way, as its most friendly to how people develop in dynamic languages, but there is nothing obsolete about the all-in-xap way. I personally prefer the script-tag way, and then I put libraries in zip files as needed. However, if you want to make a Silverlight app which runs out-of-browser, you need to use the app-in-xap way, since there in no HTML page to put script-tags on. =)
>
>    

The "Gestalt way" is definitely the cutting edge, and was brought in 
after I wrote the silverlight articles. It is "on my list" to update 
these articles...

> [snip good questions and good answers from Jimmy that I can't add to...]
>> 4) Code compilation: Is it possible to develop using IP, but to only deploy
>> compiled binaries?
>> I've stumbled over Pyc. How to use it within the best approach of question
>> (1)? My naive mind sees two possible advantages:
>>       - Could this be a solution to the traffic problem in question (2), i.e. would
>> this do without IP assembly provisioning?
>>       - For some developers it could be attractive for code obfuscation.
>> I have the feeling that things are not that easy...
>>      
> We don't support pre-compilation in Silverlight today. It wouldn't solve the traffic problem, as the DLR and IronPython are still required to run the pyc files. It might help make startup a bit quicker, but we haven't done performance testing to see what the actual win would be in Silverlight. In practice I prefer to import on a background thread, which does not hang the app during startup, and lets things load in as they need to.
>    

We would dearly love to be able to deliver compiled IronPython binaries 
with Silverlight applications - mainly for startup performance (but also 
code obfuscation which is always a controversial topic). We also use 
background thread importing but it is still not as fast as we *would 
like*... :-)

I think the limitation here is in the core-CLR missing the APIs that Pyc 
uses to write out assemblies.

All the best,

Michael Foord

-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.