On 2012-09-26 03:26, Carlo Pires wrote: > I think this idea could be extended to "have a m2 channel" from where a > handler could ask status (connections info, handlers metadata, etc). > > With that, we could add more inteligence to handlers, allowing things > like smart handlers allocation, or bandwidth throttling, etc.
The approach, per message or through a special channel will depend on the exact requirements. But effectively, we need a way to not have "dumb" handlers and "hard configured" M2 but allow a 2 way flow of information to allow M2 to handle the connection in the most appropriate way for the application. loïc > 2012/9/25 Loic d'Anterroches <[email protected] <mailto:[email protected]>> > > > > On 2012-09-25 17:38, Florian Anderiasch wrote: > > On 09/25/2012 09:37 AM, Loic d'Anterroches wrote: > >> Hello, > >> > >> On 2012-09-24 23:43, Jason Miller wrote: > >>> Hmm, I'm not sure why that's superior to not just putting the > data in a > >>> netstring? > >> > >> I suppose I was not clear enough. Basically, I want to be able to > >> exchange "meta" data with Mongrel2. We have this issue with the > headers > >> (remote ip, etc.) when the message is coming from M2 to the > handler and > >> from the handler to M2 we only have the client list and the payload. > >> What I think could be nice is to have on top of these, a > tnetstring or > >> json with some extra meta data. These extra data should be in a > >> different tnetstring/json "part" to be clear that you cannot overlap > >> them with the headers from the client. This way one have the > "trusted" > >> meta data coming from M2 directly and the headers + optional body > of the > >> request from the client. > > > > > > Can't you just work with the old X-*** headers or am I missing the > > problem completely? > > Any client can create an x-*** header and send it to the server. How do > you know it was set by Mongrel2 or by the client? > > loïc > > >
