I think a "sane subset" of supported web servers is the way to go. For 
instance, no one uses webrick anymore (most popular is mongrel for development 
and mongrel+apache/lighttpd for production), so supporting webrick isn't 
super-important. I completely agree w/the importance of being web-server 
agnostic. Also, webrick is a pure ruby app, so by definition we'll want to make 
it work in the long run.

Btw, this is really cool Wayne =)

~js

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wayne Kelly
Sent: Sunday, February 17, 2008 4:30 PM
To: [email protected]
Subject: [Ironruby-core] Towards Rails on .NET

Below is a table summarizing the extension libraries that are needed by a 
number of simple Rails use cases. These libraries are implemented in Matz's 
Ruby Interpreter in C code rather than in Ruby code, so we'll need to port or 
at least wrap them in some way.


Use Case

Win32API

Syck
(YAML)

thread

socket

stringio

zlib

digest

strscan

openssl

sqlite3_api

Setup gems

*

*

*















Gem install rails

*

*

*

*

*

*









Rails create app

*

*

*







*

*





Start WEBrick

*

*

*

*







*





WEBrick process static html page

*

*

*

*







*





WEBrick process dynamic controller page

*

*

*

*

*



*

*

*

*

IIS CGI dispatch

*

*

*







*

*

*




I'd like to start working on some of these libraries, but first want to check 
who is already working on what. I understand that John Messerly is working on a 
YAML port and according to the WIKI, Eduardo Flores is working on stringio and 
Curt Hagenlocher is working on strscan. Is this list correct and complete. Is 
anyone else already working on any of these libraries?

To support these simple use cases, typically only a small number of functions 
from these libraries is actually needed. If you are going to work on any of 
these libraries, I can provide you with a list of the actual functions and with 
the exact signature/overrides that are actually used by these use cases. 
Obviously, other functions will also be needed long term, but by implementing 
these functions first we can get basic Rails functionality happening sooner.

Note, there are many different web server options that we could persue. We 
could for example not worry about WEBrick and go straight to IIS as a host and 
so avoid implementing the socket library. Ultimately, I think we want to be web 
server agnostic, That is, we should aim to provide a drop in replacement for 
"rubyw.exe" that works regardless of which web server (IIS, Apache, WEBrick, 
Mongrel, etc) that administrators choose to adopt. That said, Windows is 
currently considered a second class platform for deploying Rails and the setup 
can be quite complex and buggy in some configurations. In the longer term we 
should aim to improve this situation. For production Rails we'll want to 
support IIS 7.0 well on server machines, but for those that just want to try it 
out, I believe we should also make sure it can be made to work on desktop 
machines such as mine with IIS 5 and XP.
Your thoughts?

Cheers, Wayne.
_______________________________________________
Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core

Reply via email to