Zlib had been discussed last year (and also the issue with including software with different licences). Below is one of the snippets (the Silverlight issues has since been resolved) from one of the archived threads. http://search.live.com/results.aspx?q=site%3Arubyforge.org+zlib+ironruby&form=QBRE should give you the other posts on that thread.
And according to http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPython&WorkItemId=2590, System.IO.Compression is able to support the Python zlib module. So it definitely sounds appealing, especially for Silverlight, where it would avoid reduce the download size of IronRuby apps since it is already included in Silverlight. John Lam said in http://rubyforge.org/pipermail/ironruby-core/2007-September/000024.html >>> After looking a bit more closely at System.IO.Compression, I think it >>> actually gives us most of what we need. >>> So in order of preference: >>> 1) System.IO.Compression (we still have to solve the Silverlight >>> problem since I just looked and saw that it doesn't ship in Silverlight). >>> 2) Component ACE zlib.net - I like the BSD style license - it will be >>> easier to make a case for this. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wayne Kelly Sent: Monday, February 18, 2008 2:35 PM To: [email protected] Subject: Re: [Ironruby-core] Towards Rails on .NET > From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of > Michael Letterle [EMAIL PROTECTED] > Sent: Monday, 18 February 2008 11:52 PM > To: [email protected] > Subject: Re: [Ironruby-core] Towards Rails on .NET > > I'd be interested in doing the zlib port if noone else has done > anything on it yet, I just recently had to dig into zlib a bit so it's > kind of fresh. Feel free to send me what needs implemented. Sounds good to me, but before we go too far down this path, perhaps we should discuss the ground rules for implementing these extension libraries. CRuby implements many of these libraries as CRuby specific thin C wrappers around functionality provided by other native open source libraries. To build CRuby for Rails from source you need to go to various other open source projects, download and compile each of their bits and make sure their binaries are present on the right path. What approaches are deemed acceptable within the IronRuby project? Firstly, is it OK to have dependences on other open source project or do we need to implement all of these components from scratch? Secondly, is it OK to have dependences on native libraries rather than on fully managed libraries? (note these are two separate issues). Having our own fully managed implementations would have many advantages, but would require more work and wouldn't keep pace with advances made in those other libraries. Wrapping the same native libraries as C Ruby will also increase our compatability. I'm not proposing policy here, I'm just raising issues and asking for guidence. The other issue is where to we put these libraries once we start developing them? It would be nice to have them all in the same place, even in their early stages of development. Each I imagine would be a separate library, so they wouldn't interfere with one another. I assume they will not become part of the IronRuby.Libraries project. Perhaps they could be put into a separate RubyForge project initially that external contributors could directly upload to, and then if necessary moved into some kind of official tree as they mature? Cheers, Wayne. _______________________________________________ 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
