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
