I haven't looked at the protocol do I've only been guessing, but it feels like a hack that will cause complexity and trouble down the road. It sounds like there's a feature missing in the existing protocol if it's so hard to pass extra data on to the handlers.
I hope somebody else will contribute their help. I can't look into it now. Please check in the mongrel2 chat room on freenode. There are usually dudes in there too. On Apr 26, 2013 1:59 PM, "Justin Karneges" <[email protected]> wrote: > The {instance} and {data} parts of a response today are pretty much > untouchable. The {tnet request id(s) string} part could possibly be > adjusted to act as the extension dict, but as far as I can tell there > wouldn't be a way to do that without breaking communication with > existing mongrels. > > On 04/26/2013 12:09 PM, Brian McQueen wrote: > > Is it not possible to keep it within the existing response, like within > > another entry in the request's tnet string? It sounds quite a bit more > > complex than i'd expect. > > > > > > On Fri, Apr 26, 2013 at 8:46 AM, Justin Karneges <[email protected] > > <mailto:[email protected]>> wrote: > > > > Hey people, > > > > I want to be able to do more with responses but I'm not sure how to > > extend the format without breaking backwards compatibility. > > > > Maybe a good way to handle this is to have mongrel2 inform its > ability > > to support additional formatting in the messages that it sends to > > workers. Then workers can respond with a non-backwards-compatible > > format, but this is okay, since they'd have confirmed that the > version > > of mongrel2 talking to them is capable of understanding it. > > > > Maybe we could use another all-uppercase header to trigger this, like > > "EXTENDED_RESPONSE" set to "1". Responses could be of the form: > > "{instance} {tnet request id(s) string} {tnet extension dict} > {data}". > > Then we can forever play with that extension dict and hopefully not > have > > to hack anything on top of the system again. > > > > One type of extension I want to add is the ability to keep-alive a > > connection (reset mongrel2's internal timer for the connection) > without > > having to actually send data down to the client. Currently, sending 0 > > data means disconnect, so we need another way. We could use the > > extension dict to set something like keep-alive=true. > > > > Really would like feedback on this before I start hacking. Thanks. :) > > > > Justin > > > > > > > > > > -- > > Make a Small Loan, Make a Big Difference - Check out Kiva.org to Learn > How! > >
