Whoa, if you want to actually understand the first paragraph, read this version =P
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:ironruby-core- > [EMAIL PROTECTED] On Behalf Of Jimmy Schementi > Sent: Thursday, May 01, 2008 12:38 AM > To: [email protected] > Subject: Re: [Ironruby-core] Opening up our tree to external committers > > Splitting into different DLLs complicates 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 > DLLs to be downloaded to the client first before loading. In > other words, the AppManifest.xaml > would have to know about ALL the IronRuby Library DLLs you "could" want > to use (and the XAP, but that's optional). > 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 _______________________________________________ Ironruby-core mailing list [email protected] http://rubyforge.org/mailman/listinfo/ironruby-core
