Florent Guillaume wrote:

> Tarek Ziadé wrote:
>> Solution
>> Add somewhere a table that keeps infos about all live requests, like:
>> - the current state: receiving | processing
>> - additional infos:
>>     receiving -> amount to receive / amount received
>>     processing -> what's beeing done (_last_obj_traversed, etc..)
>> and a few apis to get these infos
>> this could be hooked in the publisher's request classes in
>>  `processInputs()`, where we get the stream from twisted IIRC
> That's interesting, assuming we can put the right hooks in place.

Yup, I'll give a try in a branch, on BrowserRequest at first, to see how
it goes.

>> Risks
>> Could slow down the publisher 
> There's another risk to take into account: security. You'll have to
> find a way for the server to make sure it doesn't divulge sensitive
> information to the second thread querying it. The server should only
> give information to the second thread about any other thread that is
> "trusted" with that information.
> One way to ensure this would be to have some token passed by the first
> thread to the server that would also have to be presented by the
> second thread, if it wants info back.

The token idea is very nice, as long as we extend it with permissions
that would let any manager for example,  get the infos


Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to