Tickets :: Comment on [#6957] Problem with appledouble Viewer

* Your Email Address
* Spam protection	Enter the letters below: .__ ..__ . ,. . [__) \|[__) \./ \| \| \| \__\|\| \| \|/\\|
Comment	>>> 1.- When I open the message my horde session is closed, I use > >>> memcache for session container. I have follow the code and I see the > >>> 'appledouble' Viewer has a 'new MIME_Contents()' and a posterior > >>> '$mc->buildMessage()' which cause that each part(>2Mb) is cached. OK, > >>> this is the cause of my closed session because in memcache the size > >>> limit per session is 1Mb, Is this right? > >> > >> Wrong. Sounds like you did not enable 'large_items' support in > >> horde/config/conf.xml. You can also change this value in the > >> memcache source. > >> > > > > Yes, I enable 'large_items', this is my conf.php lines for memcache: > > > > $conf['memcache']['enabled'] = true; > > $conf['memcache']['hostspec'] = array('localhost'); > > $conf['memcache']['port'] = array('9000'); > > $conf['memcache']['persistent'] = true; > > $conf['memcache']['compression'] = true; > > $conf['memcache']['c_threshold'] = 0; > > $conf['memcache']['prefix'] = 'cache'; > > $conf['memcache']['large_items'] = true; > > > > > >>> This is correct?? And by other hand, Is right to store such large > >>> attachments in cache? It is better than to get directly the > >>> attachments from the IMAP Server? > >> > >> This is a known limitation with Horde's MIME implementation. See: > >> http://wiki.horde.org/Project/HordeMime?referrer=Projects#toc3 > >> > >> The short answer is - this data does not exist on the IMAP server, it > >> is an "embedded" MIME Part. Since we don't have a way to access the > >> part without parsing the entire message again (and this may be > >> difficult to do on a separate page), caching is the only way we can > >> make these messages work. > > > > Ok, but I see the following sentence at link you send me: "Remove > caching code from MIME_Contents". I think this is not the 'only way' > can make these messages work although it may be the most efficient. > >
Attachment
Watch this ticket

Saved Queries