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.
_______________________________________________
Users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
