I am agree with loic for a 1.8 release, because they have lot of bug fix, like the 100% CPU bug https://github.com/zedshaw/mongrel2/issues/131
For the next release, If they have a BC break for answer, i am pro to add BC break in the same time about the configuration, you can read the enhancement memo i have create juste after i wrote the mongoDB configuration module. https://github.com/zedshaw/mongrel2/issues/97 With read/write configuration module, and the URI, we can write very quickly lot of configuration backend, - SQL databases (MySQL, PgSQL, ...) - XML files etc ... It's will allow m2sh to write the configuration in every backend with only a first modification, all backend's write after will be compatible. I am ready to drive this part of the job, if everyone is aggree. William On Mon, May 21, 2012 at 3:01 PM, Loic d'Anterroches <[email protected]> wrote: > On 2012-05-21 13:11, Florian Anderiasch wrote: >> On 05/18/2012 04:46 PM, Loic d'Anterroches wrote: >>> More than just in case. What you are mentioning here is also a reason >>> some of the users are advocating a tnetstring answer from the handler to >>> M2 and not just a raw message. As you send a raw message at the moment, >>> outside of the "empty message" hack to close a connection from the >>> handler (or accessing the control port), you cannot do more. With a >>> tnetstring for M2, we could tell M2 to close the connection at the end, >>> rate limit, consider the message as "non valuable" in the case of >>> streaming, so if the buffer is full, just drop the message, etc. Way >>> more control, cleanly encapsulated. >> >> A bit offtopic, how's the general plan for that? >> >> I'd be more for getting out the next release as it is, and only then >> focus on this tnetstring change, if at all - as that's the hardest BC >> break we've ever had iirc. > > Should definitely go after the 1.8. We are already "late" for the 1.8 in > terms of marketing as it gives the feeling the project is a bit "dead" > at the moment. > > Note that tnetstrings to communicate back to the server is not something > agreed by everybody, but something which has been poping on the list on > a regular basis. The idea is definitely not from me. > > It would provide a lot of flexibility in the design of the filters too. > For example, you could create an embedded varnish cache. You send an > answer back from the application with a tnetstring telling which cache > level you want on the answer for the given URL, then you have a filter > on the requests which can match against the URL and conditions and > directly answer back or things like that. > > You basically open the ability to have a flexible async two-way > communication channel between the application handlers and Mongrel2. I > don't think any webserver is offering such flexibility at the moment (if > so, it always through headers hack which requires the parsing of the > answer by the server). > > loïc -- --------------------------------------------------------- William MARTIN wysman @NoSpAm@ gmail @DoT@ com
