I have uploaded the first draft of my work here: http://github.com/PlasticLizard/Bracket if anyone is interested. I generalized the Rack hosting code from the IronRuby.Rack solution to be easily adaptable to other web servers. Included in this first iteration are hosts for HttpListener, C# Web Server, Kayak, and the IIS handlers from the original project are included for completeness. Unfortunately embedding a Rack application in a C# server still requires that the IronRuby libraries are installed on the target machine or included with the applications deployment. I'm thinking of ways to make that somewhat easier to deal with, possibly embedding the standard library in a .dll via resources or doing just in time downloads of required files from the web.
-----Original Message----- From: ironruby-core-boun...@rubyforge.org [mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of Jimmy Schementi Sent: Thursday, October 08, 2009 12:23 PM To: ironruby-core@rubyforge.org Subject: Re: [Ironruby-core] Native Extensions There is no problem with you taking any part of anything in the IronRuby repo and including it in another library; here are all the licenses IronRuby's releases contain: http://github.com/ironruby/ironruby/tree/master/Merlin/Main/Languages/Ru by/Licenses. CJ recently did a good job of mapping each directory in the entire IronRuby tree to a license, so I'll let him chime in about where that data is. So, feel free to do you work separately for now. I'd be interested in taking back any fixes you have for the rack-specific pieces, so I'll figure out how to make that happen on my side when the time comes. Let me know how things go, and don't hesitate to ask any more questions, ~Jimmy ________________________________________ From: ironruby-core-boun...@rubyforge.org [ironruby-core-boun...@rubyforge.org] on behalf of Nathan Stults [nathan_stu...@hsihealth.com] Sent: Thursday, October 08, 2009 12:10 PM To: ironruby-core@rubyforge.org Subject: Re: [Ironruby-core] Native Extensions Thank you - I'm new to GitHub, so I didn't notice that branch - I'll get that one as a guide instead. On a related note, is there an accepted / preferred / traditional path I should follow in regards to re-mixing your code? I presume your rack integration stuff is licensed the same as IronRuby? In any case, is there any problem with me blending your work into a separate library intended to act as a generic adapter between Rack and an embedded .NET server and publishing as a separate library (following attribution, licensing rules, etc)? That is what I would normally do, but all this forking madness has made me second guess. BTW, thanks for your time in answering my endless questions. You guys have done an amazing job on all this stuff, very exciting possibilities. -----Original Message----- From: ironruby-core-boun...@rubyforge.org [mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of Jimmy Schementi Sent: Thursday, October 08, 2009 11:52 AM To: <ironruby-core@rubyforge.org> Subject: Re: [Ironruby-core] Native Extensions They are an implementation detail; used to manipulate the request and response from ruby (see later on down in the massive handle method). In my forks "rackupdate" branch I don't think they exist anymore, as I'm refactoring that code a bit. ~Jimmy Sent from my phone On Oct 8, 2009, at 11:12 AM, "Nathan Stults" <nathan_stu...@hsihealth.com > wrote: > Good news, thanks. In the Handle method of the IIS.cs, you are setting > two scope variables, __request and __response - are these variables > known to Rack, or are those set for the convenience of a IronRuby > adapter aware programmer to use from ruby if desired? > > Thanks, > > Nathan > > -----Original Message----- > From: ironruby-core-boun...@rubyforge.org > [mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of Jimmy > Schementi > Sent: Thursday, October 08, 2009 12:54 AM > To: ironruby-core@rubyforge.org > Subject: Re: [Ironruby-core] Native Extensions > > That lock is there because Rails wasn't thread-safe at the time of > writing; it has no reflection on whether ScriptEngine is thread- > safe. I > believe ScriptEngine is thread-safe, as only one ScriptEngine per > language can EVER exist when you have only one ScriptRuntime. > > Rails is much more thread-safe than it used to be, so that lock should > be removed; IMO it should have never been there as the Rack adapter > shouldn't care about Rails; it should lock if the rack.multithreaded > flag is true. > > ~js > ________________________________________ > From: ironruby-core-boun...@rubyforge.org > [ironruby-core-boun...@rubyforge.org] on behalf of Nathan Stults > [nathan_stu...@hsihealth.com] > Sent: Thursday, October 08, 2009 12:26 AM > To: ironruby-core@rubyforge.org > Subject: Re: [Ironruby-core] Native Extensions > > Ahh nice clean, brief code. Now this I can handle. I do have a > question > though about threading - it looks like in your implementation the > whole > apparatus is essentially single threaded, i.e. there is a single > handler > maintained by the factory, and the single handler locks itself for the > duration of the request - this suggests to me that ScriptEngine (or at > least RubyEngine) is not thread-safe? Is that the case, or was the > threading designed for simplicity? For instance, if in my > implementation > I took a lock on the RubyEngine just long enough to obtain a new scope > to handle the request, would that do? Or does it pretty much need to > be > 1 thread = 1 script engine? If the latter is the case, would there be > any caveats to maintaining a small pool of engines that could handle a > few simultaneous requests? To be honest, this almost certainly won't > make a bit of difference to my use case of embedding a web server in > an > application server, traffic just won't be that high, but mostly I'm > just > curious about the platform. > > Thanks, > > Nathan > > -----Original Message----- > From: ironruby-core-boun...@rubyforge.org > [mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of Jimmy > Schementi > Sent: Wednesday, October 07, 2009 5:12 PM > To: ironruby-core@rubyforge.org > Subject: Re: [Ironruby-core] Native Extensions > > The HttpHandler is the only piece you'll have to replace, since it's > specifically for IIS, and provide your own hookup to the server you > choose. You'll have to construct the HttpRequest/Response objects > also, > but all-in-all it should be pretty straight-forward. Those two look > like > great .NET web-server projects; "webserver" is like a web-framework > too, > which is cool. Whatever you do, DON'T use Chiron, as it's not intended > to be a real web-server (it doesn't support POST requests, and only > listens on localhost). > > ~js > >> -----Original Message----- >> From: ironruby-core-boun...@rubyforge.org [mailto:ironruby-core- >> boun...@rubyforge.org] On Behalf Of Nathan Stults >> Sent: Wednesday, October 07, 2009 4:54 PM >> To: ironruby-core@rubyforge.org >> Subject: Re: [Ironruby-core] Native Extensions >> >> I spent a day chasing my tail and, upon catching it, realized my > DLR/IronRuby >> knowledge just isn't up to the challenge. Maybe someday. As an > alternative, >> I'm going to see if the IronRuby.Rack stuff on Git can teach me >> what I > need to >> wire Rack up to one of these embeddable .NET HTTP servers: >> http://www.codeplex.com/webserver, >> http://runkayak.com/getstarted, which ought to provide the same > benefit, >> and possibly perform a little better as well. Is anyone aware of >> other >> embeddable .NET HTTP server projects? >> >> (http://github.com/jschementi/ironruby/tree/ >> 92932a672921a03210c8aefe23 >> ac >> 0a7d6996ed2d/Merlin/Main/Hosts/IronRuby.Rack) >> >> >> -----Original Message----- >> From: ironruby-core-boun...@rubyforge.org >> [mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of Daniele >> Alessandri >> Sent: Tuesday, October 06, 2009 11:39 PM >> To: ironruby-core@rubyforge.org >> Subject: Re: [Ironruby-core] Native Extensions >> >> Hi Nathan, >> yes, that's basically what you need to do: >> >> 1- rewrite the C (or Java) bits of the http parser in C# and let >> Ragel > generate >> the rest >> 2- wrap everything up in a layer to expose the needed methods to > IronRuby >> 3- make sure to require your newly built http11.dll in the ruby part > of the >> mongrel library >> 4- have fun. >> >> I did the same for hpricot and json (whose parsers are generated >> using >> Ragel), so I guess that should work for Mongrel too :-) >> >> >> On Wed, Oct 7, 2009 at 03:09, Nathan Stults > <nathan_stu...@hsihealth.com> >> wrote: >>> Thanks for the tip. It looks like the Http Parser is generated via >>> Ragel, and it appears there is a Java version of the language file, > so >>> theoretically all I should have to do is learn Ragel and port that >> file >>> to C#, piece of cake :) Then I suppose I'd need a patched version of >>> mongrel that required the new .NET HTTP parser dll instead of the C >>> version? Is that how that would work? >>> >>> -----Original Message----- >>> From: ironruby-core-boun...@rubyforge.org >>> [mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of Jimmy >>> Schementi >>> Sent: Tuesday, October 06, 2009 6:00 PM >>> To: ironruby-core@rubyforge.org >>> Subject: Re: [Ironruby-core] Native Extensions >>> >>> Native extension support is not on the roadmap for 1.0. Win32OLE >> support >>> is actually in there now, because of the Dynamic Language Runtime's >>> support for dispatching to COM objects. So IronRuby's version of >>> win32ole.rb uses IronRuby's OLE support, rather than depending on >> native >>> code. >>> >>> The current work-around for libraries which use native code to >>> communicate with the OS or Ruby is to rewrite those using .NET so >>> IronRuby can use them. Mongrel is actually \mostly Ruby code, as > most >>> Ruby libraries which use native code; there is usually a very small >> part >>> of the library which depends on native code. For Mongrel, the HTTP > 1.1 >>> parser is the only native piece; rewriting that in C# would allow > you >> to >>> run Mongrel on .NET. >>> >>> IMO, after 1.0 would be the time to consider supporting the native >> Ruby >>> API. >>> >>> ~Jimmy >>> ________________________________________ >>> From: ironruby-core-boun...@rubyforge.org >>> [ironruby-core-boun...@rubyforge.org] on behalf of Nathan Stults >>> [li...@ruby-forum.com] >>> Sent: Tuesday, October 06, 2009 4:18 PM >>> To: ironruby-core@rubyforge.org >>> Subject: [Ironruby-core] Native Extensions >>> >>> I noticed on the road-map this item under .NET Interop: >>> >>> [P3] COM: for Win32OLE compatibility >>> >>> Is that the same thing as supporting native extensions? If not, is > it >> on >>> the roadmap to support such a thing? Also, is there a workaround, > like >>> replacing files in the gem installation with a .NET wrapper? I'd > love >> to >>> use IronRuby to embed Thin or Mongrel in my .NET services, but from >> from >>> my few experiments it looks like most of the networking libraries >> these >>> servers use tend to rely on native dll's. >>> -- >>> Posted via http://www.ruby-forum.com/. >>> _______________________________________________ >>> Ironruby-core mailing list >>> Ironruby-core@rubyforge.org >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >>> _______________________________________________ >>> Ironruby-core mailing list >>> Ironruby-core@rubyforge.org >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> _______________________________________________ >>> Ironruby-core mailing list >>> Ironruby-core@rubyforge.org >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >> >> >> >> -- >> Daniele Alessandri >> http://www.clorophilla.net/blog/ >> http://twitter.com/JoL1hAHN >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core@rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core@rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core@rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > _______________________________________________ > Ironruby-core mailing list > Ironruby-core@rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core@rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > _______________________________________________ > Ironruby-core mailing list > Ironruby-core@rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > _______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core _______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core _______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core _______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
