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!
