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 > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:ironruby-core- > [EMAIL PROTECTED] On Behalf Of Curt Hagenlocher > Sent: Wednesday, April 30, 2008 8:50 PM > To: [email protected] > Subject: Re: [Ironruby-core] Opening up our tree to external > committers > > On Wed, Apr 30, 2008 at 8:36 PM, M. David Peterson > <[EMAIL PROTECTED]> wrote: > > > On Wed, 30 Apr 2008 21:14:23 -0600, Curt Hagenlocher > <[EMAIL PROTECTED]> wrote: > > > > One advantage of having "one dll per library" is that you can > make > decisions about which DLL to load based solely on the library name. > Once you have multiple libraries per DLL, you need a more complicated > probing or mapping scheme to know which assembly to load. > > > > Why not meet half way: Generate netmodules who's primary purpose, if > I am remembering correctly, is the ability to be merged together into > a final assembly. > > > This isn't dynamic, though. There has to be a single manifest for the > assembly that lists all the netmodules. I imagine it would be > desirable to be able to add a new library simply by copying it into > the appropriate directory without having to register it or relink the > assembly. > > -- > Curt Hagenlocher > [EMAIL PROTECTED] _______________________________________________ Ironruby-core mailing list [email protected] http://rubyforge.org/mailman/listinfo/ironruby-core
