[Ironruby-core] zlib for Rail on .NET

Shri Borde Shri.Borde at microsoft.com
Tue Feb 19 02:38:35 EST 2008

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: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Wayne Kelly
Sent: Monday, February 18, 2008 2:35 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Towards Rails on .NET

> From: ironruby-core-bounces at rubyforge.org [ironruby-core-bounces at rubyforge.org] On Behalf Of
> Michael Letterle [michael.letterle at gmail.com]
> Sent: Monday, 18 February 2008 11:52 PM
> To: ironruby-core at rubyforge.org
> 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
Ironruby-core at rubyforge.org

More information about the Ironruby-core mailing list