> -----Original Message-----
> From: [email protected] [mailto:users-
> [email protected]] On Behalf Of Jan-Philip Gehrcke
> Sent: Friday, July 02, 2010 11:02 AM
> To: [email protected]
> 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
> [email protected]
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

_______________________________________________
Users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Reply via email to