similar to: Ebb Web Server

Hey so, People are asking about Mongrel Ruby 1.9 compatibility. Isn''t the point of 1.9 for library developers to have time to get ready for 2.0? It''s not like 1.9 is a production release. Evan -- Evan Weaver Cloudburst, LLC

I''m modifying techno weenie''s progress bar plug-in. Currently it works by making the browser poll the server, via AJAX, for updates on amount received. My plug-in provides a handler which will stream updates on the amount received, thus only one request needs to be made. Also, the progress can be updated at faster rates since the client doesn''t need to poll. This should

hi, I rewrote escape, unescape, and query_parse in a C extension. http://s3.amazonaws.com/four.livejournal/20070922/http_helpers.tar.bz2 Here are some sample benchmarks (the benchmark script is included in the package) user system total real escape: Single long Mongrel: 1.680000 0.020000 1.700000 ( 1.837793) HttpHlp: 0.030000 0.010000 0.040000 ( 0.036590)

Hello I''m attempting to write a mongrel plug-in which would stream a response. At first I was doing this def process(request, response) response.start do |head,out| head[''Content-Type''] = ''text/html'' %w{o m g}.each { |c| out.puts c; sleep 5; } end response.done = true end But then I looked at HttpResponse and decided

Hello all, Last week, I finally decided to put into motion some ideas I''ve been kicking around for a year in my head since last year... Basically I don''t want to have to deal with threads or support platforms that rely on or encourage threads. Especially given MRI 1.9 where kernel threads are more difficult to debug than green ones. Given the limited scope of this project,

Hi mongrelians, I found myself with an unloaded full production server recently which presented an opportunity to run some performance tests against Mongrel and nginx. I thought this list might have some interest in the results of my tinkering! I actually ran two sets of studies, and Wayne Seguin kindly provided a lot of guidance and support in getting them running. Thanks Wayne! Also,

Before anything else, let me state this: Of course it''s going to be PAINFULLY slow on MRI. That''s not the point :) I thought I''d try out writing out a Ruby version of the parser for the purposes of Rubinius. For those of you who aren''t aware, Ragel supports a goto-driven FSM on Rubinius by injecting assembly directly, and Rubinus head honcho guy Evan Phoenix

Hi Zed, I checked in a pure-Ruby URI classifier to Mongrel trunk. Ola''s Java port of the TST had some bug, and I don''t think it''s necessary in the first place. The Ruby classifier is around 25 lines instead of the 400-odd lines for the C extension and the 200-odd for the Java extension. It uses a Regexp which is perhaps shady: @matcher = Regexp.new(routes.map do

I like the cookie sessions that Rails edge has - they make sense, they''re fast, easy. For those that don''t know: the default session mechanism is to give developers a Hash called session. To store this object between requests it Marshals the session object and sends the object itself (now as a bitstream) back to clients to store in their cookie file. To prevent users from

I have a magical proposal for the anti-magic web framework. Controller methods do not use arguments and yet expect arguments. This is handled through this params hash because we don''t know in advance what parameters a client could pass to Merb. But in almost every instance, it is too much to know all the query parameters - one doesn''t care if the user threw in an extraneous

This class provides a CookieJar object for Mongrels. Just initialize with response and request objects and then treat like a hash. Does not depend on cgi.rb ry -------------- next part -------------- A non-text attachment was scrubbed... Name: cookies_for_mongrels.rb Type: text/x-ruby-script Size: 4776 bytes Desc: not available Url :

Trunk Issue: Because of the use of ''autoload'', template handlers other than Erubis are not loaded automatically (Haml, XMLBuilder). Either this should be fixed, or the documentation should be updated to instruct people how to use non-Erb template engines. Apparently the solution is to do something like this in merb_init.rb: ::Merb::AbstractController.register_engine

I''m working on new methods of doing Ajax calls through streaming responses. I''ve created a little javascript library (which depends on prototype.js) that can interpret a stream of JSON objects separated by semicolons. As an application of this, this Mongrel plug-in streams upload status when given a qualified upload_id. It looks like this:

Ez (or someone) asked on #merb tonight whether respond_to was the right API for what it does. After some discussion and pasties, I offer the following proposed API for content negotiation and response format selection: First, what does respond_to do right now? I see at as performing 3 distinct operations: 1. parse params[:format] and the accepts header to find out what format the

SqueezeBox is a simple file system based routing framework for erubis templates. It aims for a couple of niceties as well: Instead of putting your logic inside your template, like you would with PHP, SqueezeBox recognizes a separate logic file to be called before it loads the template. This allows you room to load ActiveRecord models or do calculations. These logic files return to the webserver

hello list! I like merb a lot, it frees me from dropping to mongrel every time i want to stream something. i have an action which will stream a list of JSON objects (separated by semicolons). unfortunately because of Mongrel''s write-only header hash, once a Content-Length header has been written, I can never again tell it to not send such a thing - and streaming doesn''t work if

It seems that Merb is sending static files with Mongrel::DirHandler. (mongrel_handler.rb:52) if get_or_head and @files.can_serve(path_info) # File exists as-is so serve it up MERB_LOGGER.info("Serving static file: #{path_info}") @files.process(request,response) I haven''t done benchmarks and I''ve hardly glanced at DirHandler''s code but the

Hello Guys, I''m reviewing the code for 1.9, and forgot about this when we first spoke on this subject. The current way we stop threads is using Thread#raise to spread StopServer exception, which will not work as expected in 1.9. 1.9 will treat raised exceptions as #kill, like JRuby does, so the worker threads will not finish serving the client and _then_ exiting, but will be

merb_dispatcher.rb:28 controller = klass.build(request.body, request.params, route, response) Why not just use a typical constructor? merb_dispatcher.rb:35 raise Merb::HTTPMethodNotAllowed.new(method, allowed) Why not check for this after the action has been dispatched to the controller? controller_mixin.rb:149 def query_parse(qs, d = ''&;'') Why not offload query parsing

Guys, Just for fun, I tried to see (I know, a silly way to test it) how much overhead we have calling the C functions of the extensions. the benchmark script and the results: http://pastie.caboo.se/128646 The naive C extension: http://pastie.caboo.se/128647 I compared 1.8.6 (VC6 and mingw builds) against a fresh checkout of ruby trunk. What I understand from that is 1.9 is slower than 1.8