Re: [Twisted-Python] Twisted protocol instances : a puzzle

2010-10-17 Thread Marcus.CM
Hi Exarkun, Ah, that should work correctly and as catered in the framework. Btw, for imap4.py i have a suggestion to improveĀ  the performance in fetch : Fetch can be an expensive operation if the number of messages is a lot, this can be more "reactor" friendly if we use "fetch" as a genera

Re: [Twisted-Python] Twisted protocol instances : a puzzle

2010-10-17 Thread exarkun
On 16 Oct, 02:02 pm, mar...@internetnowasp.net wrote: >Hi, > >This might seems like a trivial question or at least i would have >thought so but it has eluded me for some time on how to do this >elegantly. >In twisted mail, since the only part where we instantiate an instance >of >account is unde

Re: [Twisted-Python] Twisted protocol instances : a puzzle

2010-10-17 Thread Marcus.CM
Hi, Ok assuming that we work on the model that if "connectionLost" is called, i can set a flag. But from the twisted model, in RequestAvatar, the "mind" is not set to the instance of the protocol, so there is no way to reference the instance of the protocol? Referencing the factory itself is o

Re: [Twisted-Python] Twisted protocol instances : a puzzle

2010-10-16 Thread Glyph Lefkowitz
On Oct 16, 2010, at 10:02 AM, Marcus.CM wrote: > How do i find out if a particular connection is already dead in the > given "account" class? There's no way to know; it's a race condition. If the connection dies before authentication, then requestAvatar won't be called. If the connection die

[Twisted-Python] Twisted protocol instances : a puzzle

2010-10-16 Thread Marcus.CM
Hi, This might seems like a trivial question or at least i would have thought so but it has eluded me for some time on how to do this elegantly. In twisted mail, since the only part where we instantiate an instance of account is under : def requestAvatar(self, avatarId, mind, *interfaces):