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]> 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!
