[imp] pgp-encrypted emails blowing up session

[Michael M Slusarz]

Quoting Oliver Kuhl <okuhl at netcologne.de>:

> Michael M Slusarz wrote:
>
>> Quoting Oliver Kuhl <okuhl at netcologne.de>:
>>> I looked at the size of my session and found out that reading encrypted
>>> emails blows the session, because the decrypted email seems to be saved
>>> in the session everytime I open it again and again.
>>
>> There is nothing wrong here.  An unfortunate side effect of a session-based
>> environment (i.e. PHP) is the need to cache information between page loads
>> since we can not keep that information in memory as it will be lost when the
>> pageload is terminated.  Thus, we have to cache all MIME objects to 
>> prevent us
>> from having to redo the (potentially expensive) process of building 
>> up the MIME
>> Structure/contents/etc.
>
>> So, if you have a large amount of data in these embedded MIME parts, 
>> they will
>> take up a large amount of space in the cache backend.  Since our caching
>> algorithim does not recognize that we have already cached an item (it won't
>> know that we cached IMAP index 1 once you leave the page), it has to 
>> create a
>> new cache object every page load.  This is why you are seeing the 
>> increase in
>> size.
> If I understand you right, the caching of horde just caches things in
> context of _one pageview_ and does not reuse everthing cached the next
> time I view the same page again? The cache makes sense, because you use
> the MIME parts of a message more then once during page creation (that's
> what you tried to tell me with the IMAP index 1, Part 2.2 with encrypted
> mails, didn't you?). Hmm - but that's not what I expected.
>
> Is there any specific reason besides it's simply not yet implemented why
> you cannot reuse the stuff?

Because right now the object is cached through the MIME_Contents::_addCache()
function call.  MIME_Contents:: has absolutely no knowledge of anything to do
with IMAP indexes, folders, etc. so it can't be done there.

Now IMP_Contents:: does have knowledge of the IMAP index, so a solution where
IMP_Contents overrides the inherited _addCache() solution would be a solution.
If someone wanted to work on this, that would be great.

michael

______________________________________________
Michael Slusarz [slusarz at bigworm.colorado.edu]
The University of Colorado at Boulder