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

Jimmy Schementi Jimmy.Schementi at microsoft.com
Fri Jul 2 20:34:28 CEST 2010


> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Jan-Philip Gehrcke
> Sent: Friday, July 02, 2010 11:02 AM
> To: users at lists.ironpython.com
> Subject: [IronPython] Developing Silverlight apps using IronPython -- best
> strategies
> 
> Dear list,
> 
> I'm totally new to Silverlight (SL) development and it seems that I can benefit
> from my Python experience by combining SL with IronPython (at which I've
> never looked before, too). In the last days, I crawled the web and tried to get
> an impression of what is the best way to start.
> During this time, some questions came up...

Awesome, I'll give thoughts on these questions:

> 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. =)

> 2) Are IP based SL applications creating much more traffic than compiled
> (C#...) ones?
> It seems to me that the IronPython assemblies either have to be delivered
> within the xap archive or by an external resource, but definitely on *each*
> application load, resulting in ~1 MB traffic per load, even for very small apps
> (okay, the browser cache will definitely help here..). If this is true, isn't this a
> huge disadvantage over compiled solutions? Is the browser cache the only
> help at this point or are there better solutions?

For the all-in-xap way, by default IronPython's assemblies are embedded in the XAP, which means that every time that app gets downloaded the full payload comes too. You can also put them on your web-server, which means all your apps can share one set of assemblies, and your users will see them download once (browser caching). For gestalt, you have the added benefit of using IronPython's assemblies from gestalt.ironpython.net, which means ALL apps that use it share the same assemblies, and a user is more likely to have it on their machine. 

Personally, I don't see this as any different than requiring your users have Silverlight installed ... =)

> 3) Which -- in your opinion -- is the best environment for developing an IP
> based SL app?
> For the first time, I installed Visual Web Developer..., then Visual Studio 2010
> shell and the IronPython tools CTP3. I still have to get into this.. Which tools
> do *you* use for developing IP/SL apps?

Because there is really no tools requirement, I use the same tools that I would use to develop a JavaScript+HTML app: my favorite text editor and a browser. IronPython tools will give you syntax highlighting of Python code, and F5-launch-browser, but there is still a lot to be desired (eg. intellisence doesn't look at the Silverlight assemblies yet). Michael Food uses WingIDE, and really any Python editor is appropriate. Keep in mind you can still use Blend or VS to work on any XAML UI, or even a HTML editor, regardless of what tool you choose to use for IronPython.

> 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.

> Because things are not very clear to me at the moment, my questions are not
> totally clear, too and leave (too) much room for answers, sorry for that. ;-)
> Anyway, I'm sure that your comments will help me to get a better overview,
> a better technical understanding and to get the feeling to start with the right
> way.

Let me know if you have any more questions; this is all perfect info to go on the website, so thanks for helping seed that content =)

> All the best,
> 
> Jan-Philip Gehrcke
> http://gehrcke.de
> 
> PS: I already sent an email yesterday, without having subscribed to the list
> before. It did not show up in the archives until now. I think
> (hope) that this old mail is in a black hole now and I did not produce a
> doublet.
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com




More information about the Ironpython-users mailing list