[Ironruby-core] Opening up our tree to external committers
Jimmy.Schementi at microsoft.com
Thu May 1 03:42:07 EDT 2008
Whoa, if you want to actually understand the first paragraph, read this version =P
> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-
> bounces at rubyforge.org] On Behalf Of Jimmy Schementi
> Sent: Thursday, May 01, 2008 12:38 AM
> To: ironruby-core at rubyforge.org
> 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
> 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?
> > -----Original Message-----
> > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-
> > bounces at rubyforge.org] On Behalf Of Curt Hagenlocher
> > Sent: Wednesday, April 30, 2008 8:50 PM
> > To: ironruby-core at rubyforge.org
> > Subject: Re: [Ironruby-core] Opening up our tree to external
> > committers
> > On Wed, Apr 30, 2008 at 8:36 PM, M. David Peterson
> > <m.david at xmlhacker.com> wrote:
> > On Wed, 30 Apr 2008 21:14:23 -0600, Curt Hagenlocher
> > <curt at hagenlocher.org> 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
> > 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
> > curt at hagenlocher.org
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
More information about the Ironruby-core