views:

87

answers:

4

Having just found out that you can use Ruby or Python inside a SilverLight application..

link here

..I wonder if its possible to bypass some of the SilverLight limitations with use of these languages instead of C#.

I know that the Ruby Engine inside the SilverLight application is trimmed down, just as the .NET CLR is, so I would like to know that even without all the functionality of a full Ruby or Python Engine:

Can I still be able to do something with the use of these dynamic languages that I wouldn't be able to do in C# SilverLight?

.

If we need to download something built by the community to extend the cut down Ruby implementation (to support Interop calls for instance?), what's the impact on deployment?

.

If not, if you cannot do anything you wouldn't be able to with c#, with these engines, besides the typical benefit of a dynamic language, and not really circumventing some of the restrictions of the SilverLight's CLR, why would one choose to use Ruby in a SilverLight application?

One of my interest points is use of sockets, socket usage in SilverLight is improving in each version, but it can still be troublesome because of the xml authorization file required on the server side..would ruby be able to make this unnecessary?

Thanks,

Ric

+2  A: 

I suspect you won't be able to work around that. Keep in mind that it's not the language imposing the limitations here but the runtime. TO be precise, it's Silverlight itself. Since both C# and Ruby are compiled to CIL in this case you're left with more or less the exact same capabilities (except some differences in the typing system).

Joey
+1  A: 

I'm not sure what you're getting at. Regardless of language you are still running inside the same "sandbox", security model and limited with the same cutdown libraries in Silverlight. You can extend the bits that you feel are "limited", assuming your code doesn't violate the security model, with any language.

You might be able to do things differently using another language, but the same basic constraints still apply.

Steven Robbins
A: 

You need to make sure the files are included in the xap or use the silverlight 3 slvx system to stream the assemblies defined in C# or VB etc.

The ruby language should be a complete ruby implementation so you can use all the language features ruby offers like metaprogramming etc. All source files need to be included in the xap to work. If you're using ruby then you get gestalt too and you can include ruby source files in the same way as you include javascript files in an html page today.

Casual Jim
A: 

One of the best scenario for the usage of dynamic languages in .NET is to let the users extend the application with their own code, so that's the main reason I use IronPython in my Silverlight application. It's so nice to have that available in the limited .NET runtime of Silverlight. It's really easy to integrate (although I had a hard time making C# extension methods visible to Python) and it can be very powerful for the users.

devMomentum