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.

Do I am expressing myself a bit better now?
loïc

> On 19:39 Mon 17 Sep     , Loic d'Anterroches wrote:
>> Hi Jason,
>>
>> the wire format when "answering" from the handler is a set of
>> destination clients and then a payload. Why not putting a set of
>> destination clients, a tnetstring with some special data (you could
>> define there a "drop if the client cannot handle" for streaming or
>> things like the x-send specs) and then the payload.
>>
>> The same thing, when sending to the handler, we could have a tnetstring
>> with meta data, the client headers and then the payload. The meta data
>> could be the client IP and everything not really sent by the client but
>> usually "added on the way" by the servers.
>>
>> This way you could have a transit of information without
>> mangling/overwritting the request data.
>>
>> I am not sure I am totally clear.
>>
>> loïc
>>
>> On 2012-09-17 19:33, Jason Miller wrote:
>>> Hi Loïc,
>>>
>>> I'm not sure what you're saying, could you give an example?
>>>
>>> -Jason
>>>
>>> On 14:19 Mon 17 Sep     , Loic d'Anterroches wrote:
>>>> Hello,
>>>>
>>>> short question. Why not directly "breaking" the wire level protocol and
>>>> get in the payload from and to the handlers an extra tnetstring (or json
>>>> from Mongrel2) part with additional metadata?
>>>>
>>>> This would allow any kind of communication between the M2 and the handlers.
>>>>
>>>> loïc
>>>>
>>>> On 2012-09-15 03:28, Jason Miller wrote:
>>>>> In the developo branch of my fork (https://github.com/jasom) I've
>>>>> created a new type of plugin system for handling replies from handlers.
>>>>> Included is a simple "sendfile" type implementation
>>>>> (tools/filters/sendfile.c).  You can add it to a server similarly to how
>>>>> you do a Filter:
>>>>>
>>>>> sendfile=Xrequest(name="tools/filters/sendfile.so",settings={})
>>>>>
>>>>> main = Server(
>>>>> ...
>>>>>     xrequests=[sendfile],
>>>>> ...
>>>>>     )
>>>>>
>>>>> Before pulling this into the main repository I thought I'd ask for any
>>>>> comments about it.  If you want to test the sendfile plugin you can do
>>>>> that as well.  There is an example of how to do that in
>>>>> examples/http_0mq/sendfile.py; As you can see the extended request
>>>>> format is just like a normal handler deliver, except the first ID is "X"
>>>>> instead of a number.  The payload must be a tnetstring, and can be
>>>>> anything serializable in tnetstrings, whic would allow e.g. sending
>>>>> dictionaries for doing fancy stuff in plugins.
>>>>>
>>>>> -Jason
>>>>>
>>>>
>>>> -- 
>>>> Dr Loïc d'Anterroches
>>>> Founder Céondo Ltd
>>>>
>>>> w: www.ceondo.com       |  e: [email protected]
>>>> t: +44 (0)207 183 0016  |  f: +44 (0)207 183 0124
>>>>
>>>> Céondo Ltd
>>>> Dalton House
>>>> 60 Windsor Avenue
>>>> London
>>>> SW19 2RR / United Kingdom
>>>
>>>
>>
>> -- 
>> Dr Loïc d'Anterroches
>> Founder Céondo Ltd
>>
>> w: www.ceondo.com       |  e: [email protected]
>> t: +44 (0)207 183 0016  |  f: +44 (0)207 183 0124
>>
>> Céondo Ltd
>> Dalton House
>> 60 Windsor Avenue
>> London
>> SW19 2RR / United Kingdom
> 
> 

-- 
Dr Loïc d'Anterroches
Founder Céondo Ltd

w: www.ceondo.com       |  e: [email protected]
t: +44 (0)207 183 0016  |  f: +44 (0)207 183 0124

Céondo Ltd
Dalton House
60 Windsor Avenue
London
SW19 2RR / United Kingdom

Reply via email to