[Ironruby-core] Opening up our tree to external committers

Ryan Riley ryan.riley at panesofglass.org
Thu May 1 09:49:00 EDT 2008

On Thu, May 1, 2008 at 2:37 AM, Jimmy Schementi <
Jimmy.Schementi at microsoft.com> wrote:

> Splitting into different DLLs complicate things for Silverlight.
> On the desktop you can have the assembly loading be dynamic with a foo.rb
> wrapper for a library. However, Silverlight (today) requires the DLL would
> have to be downloaded to the client first before loading. In other words,
> the AppManifest.xaml (and the XAP, but that's optional) would have to know
> about ALL the IronRuby Library DLLs you "could" want to use. We automate the
> generation of this file and XAP, so that tool (Chiron) would need to know
> this. While this isn't a direct problem, it does make the # of assemblies
> you need to include with your app go from 2 to n. Splitting could
> potentially save download size, but figuring out which DLLs to include is
> hard (see below).
> Are there other options for how to get DLLs onto a client machine?
> To get this option out of the way, we can't bake this logic (download an
> assembly when you require it) into our Silverlight integration, or even push
> the responsibility on the libraries themselves. Downloading in SL requires
> asynchronous requests, and we can't pause user code to do this (aka.
> Continuations). We could technically implement it by hacking on
> XmlHttpRequest directly to get synchronous support, but ugh. If network
> connection gets flakey your browser hangs ... not very pleasant.
> Do we introduce a config.rb to Silverlight that lets you define the
> closure of all the assemblies you'll need? This file gets loaded first, it
> triggers the downloads the necessary assemblies, and then load the real
> program?
> Again, the AppManifest solution will work, but it's not very
> dynamic-language-esc, and becomes more apparent if we split the libraries
> out. I'm just brainstorming for better solutions to this. Ideas?
> ~Jimmy

 Wouldn't this, then, lend itself toward a solution towards that proposed by
/M:D? I don't know multi-file assemblies that well, but it seems the best
solution in that, iirc, only the .netmodules needed are loaded as they are
called, but they're already linked by the primary assembly. This might be
more complicated to maintain and cleanly build; I don't know. I also don't
quite understand the "not dynamic" comment, but again, I'm not too familiar
with multi-file assemblies.

(Also, apologies for the duplicate in the other thread.)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20080501/a6278c56/attachment.html>

More information about the Ironruby-core mailing list