Am 27.06.2012 09:32, schrieb Wojciech Puchar:
>>
>> Hi, i dont wanna flame into this thread, cause its heavy tec stuff
>> which i dont really fit in
>>
>> but for some webmail you can use http://imapproxy.org/
>
> the discussion was about if running proxy at all make sense.
>
> Proxies are to red
Hi, i dont wanna flame into this thread, cause its heavy tec stuff
which i dont really fit in
but for some webmail you can use http://imapproxy.org/
the discussion was about if running proxy at all make sense.
Proxies are to reduce traffic or server load by avoiding repetitive
requests.
Wi
Am 27.06.2012 07:44, schrieb Wojciech Puchar:
>>
>> Timo: I'm not sure if you are saying that all client-side caching is
>> wrong. If so, I'm going to disagree with you, especially when dealing
>> with more complex data structures.
>
>
> it is always good - on WAN links.
Hi, i dont wanna flame i
Timo: I'm not sure if you are saying that all client-side caching is wrong.
If so, I'm going to disagree with you, especially when dealing with more
complex data structures.
it is always good - on WAN links.
Quoting Timo Sirainen :
Well, I had completely forgotten about it :) Reading my old mail:
There isn't a whole lot of state to be saved really. Mailbox GUID,
UIDVALIDITY,
HIGHESTMODSEQ gives the mailbox state. Then you have the
language/etc. states.
Clients could restore their earlier state
Quoting Wojciech Puchar :
It's stupid how webmail works but dovecot doesn't have a problem to
get new connections every now and then. just make sure you didn't
set up SSL by accident.
Would you mind explaining why you think it is "stupid" the way webmail
works? I assume you are angry bec
Quoting Timo Sirainen :
On 23.6.2012, at 13.21, Ed W wrote:
But I don't know, whether this is the sort of caching you are
referring to.
what's a point of caching imap, except your webmail service is not
locally connected (localhost or LAN) to imap server?
Asking for items 600-615 from a
wehre your webmail is running and configure the webmail for
using 127.0.0.1 - so only one connection per user is
persistent instead make a new one for each ajax-request
Someone benchmarked Dovecot a while ago in this list with and without imapproxy
and the results showed that imapproxy simply s
On Thu, Jun 21, 2012 at 11:44:33PM +0300, Timo Sirainen wrote:
> >
> > additionally you should install imapproxy on the webserver
> > wehre your webmail is running and configure the webmail for
> > using 127.0.0.1 - so only one connection per user is
> > persistent instead make a new one for each
Asking for items 600-615 from a threaded list, sorted by something, can be an
expensive operation, especially if you just asked for items 585-600 a moment
ago?
Can be, but is it? :) Dovecot attempts to cache/index stuff as well. Normally
there shouldn't be a need for extra caching layer exce
On 23.6.2012, at 13.21, Ed W wrote:
>>> But I don't know, whether this is the sort of caching you are referring to.
>>
>> what's a point of caching imap, except your webmail service is not locally
>> connected (localhost or LAN) to imap server?
>
> Asking for items 600-615 from a threaded list,
But I don't know, whether this is the sort of caching you are referring
to.
what's a point of caching imap, except your webmail service is not locally
connected (localhost or LAN) to imap server?
Asking for items 600-615 from a threaded list, sorted by something, can be an
expensive operatio
On 23/06/2012 09:22, Wojciech Puchar wrote:
Nearly all of them are non-caching. (I don't know of any caching ones.)
At least roundcube (v0.7.1 here) has some caching options:
--[excerpt from roundcubes main.inc.php]-
// Type of IMAP indexes cache. Supported values:
Nearly all of them are non-caching. (I don't know of any caching ones.)
At least roundcube (v0.7.1 here) has some caching options:
--[excerpt from roundcubes main.inc.php]-
// Type of IMAP indexes cache. Supported values: 'db', 'apc' and 'memcache'.
$rcmail_config['i
Nearly all of them are non-caching. (I don't know of any caching ones.)
which is definite adventage in spite of it's numerous security holes.
We are building a new system that will support a large number of users (high
volume, high concurrent usage, etc).
what is large?
We have played with Dovecot, but in most serious applications we have
traditionally used Courier IMAP.
It's my (lay) understanding that with indexing and perha
On 22.6.2012, at 8.27, email builder wrote:
> So really, a new process is created under *two* circumstances? 1. when a
> process reaches client_limit number of *simultaneous* connections or 2. when
> a process has serviced service_count number of connections. Is this correct?
Yes.
> So for se
>>> Oh, and of course it also depends on Dovecot configuration :)
>>> Authentication
>>> cache is needed and login processes must be in high performance mode.
>>
>> I.e., I think:
>>
>> http://wiki2.dovecot.org/LoginProcess
>> http://wiki2.dovecot.org/Authentication/Caching
>
> Yes.
>
>
On 22.6.2012, at 5.28, email builder wrote:
>> Oh, and of course it also depends on Dovecot configuration :) Authentication
>> cache is needed and login processes must be in high performance mode.
>
> I.e., I think:
>
> http://wiki2.dovecot.org/LoginProcess
> http://wiki2.dovecot.org/Authentica
> Oh, and of course it also depends on Dovecot configuration :) Authentication
> cache is needed and login processes must be in high performance mode.
I.e., I think:
http://wiki2.dovecot.org/LoginProcess
http://wiki2.dovecot.org/Authentication/Caching
> There is
> still the extra work of fork
On 22.6.2012, at 0.58, Michael M Slusarz wrote:
>> I think the conclusion is that imapproxy is not necessary. There are some
>> advantages (eg with high network latency between web and imap server, and
>> reducing apparent login count), and some disadvantages (extra complexity,
>> slowdown)
>
Quoting Ed W :
I think the conclusion is that imapproxy is not necessary. There
are some advantages (eg with high network latency between web and
imap server, and reducing apparent login count), and some
disadvantages (extra complexity, slowdown)
Not entirely true. See this thread:
htt
On 21/06/2012 21:37, René Neumann wrote:
Am 21.06.2012 22:22, schrieb Timo Sirainen:
On Thu, 2012-06-21 at 13:05 -0700, email builder wrote:
Do you know what webmails are caching vs. non-caching?
Nearly all of them are non-caching. (I don't know of any caching ones.)
At least roundcube (v0.7.
On 21/06/2012 21:54, Reindl Harald wrote:
and last but not least i have lesser entries in maillog which
goes to a central mysql-server for self-developed web-interfaces
I recently added imapproxy to my Roundcube installation. Benchmarks
showed a very slight slowdown, but as you point out it r
Quoting Timo Sirainen :
On Thu, 2012-06-21 at 13:05 -0700, email builder wrote:
Do you know what webmails are caching vs. non-caching?
Nearly all of them are non-caching. (I don't know of any caching ones.)
IMP is caching (message/mailbox/folder listing), with full
QRESYNC/CONDSTORE suppo
On 21.6.2012, at 23.48, Reindl Harald wrote:
>> Someone benchmarked Dovecot a while ago in this list with and without
>> imapproxy and the results showed that imapproxy simply slowed things down by
>> adding extra latency. This probably isn't true for all installations, but I
>> don't think the
Am 21.06.2012 22:52, schrieb Timo Sirainen:
> On 21.6.2012, at 23.48, Reindl Harald wrote:
>
>>> Someone benchmarked Dovecot a while ago in this list with and without
>>> imapproxy and the results showed that imapproxy simply slowed things down
>>> by adding extra latency. This probably isn't
On 21.6.2012, at 23.48, Reindl Harald wrote:
>> Someone benchmarked Dovecot a while ago in this list with and without
>> imapproxy and the results showed that imapproxy simply slowed things down by
>> adding extra latency. This probably isn't true for all installations, but I
>> don't think the
Am 21.06.2012 22:44, schrieb Timo Sirainen:
> On 21.6.2012, at 23.34, Reindl Harald wrote:
>
>> Am 21.06.2012 22:22, schrieb Timo Sirainen:
Do you know what webmails are caching vs. non-caching?
>>>
>>> Nearly all of them are non-caching. (I don't know of any caching ones.)
>>
>> roundcub
On 21.6.2012, at 23.34, Reindl Harald wrote:
> Am 21.06.2012 22:22, schrieb Timo Sirainen:
>>> Do you know what webmails are caching vs. non-caching?
>>
>> Nearly all of them are non-caching. (I don't know of any caching ones.)
>
> roundcube can if configured
>
> additionally you should insta
On Jun 21, 2012, at 3:22 PM, Timo Sirainen wrote:
> On Thu, 2012-06-21 at 13:05 -0700, email builder wrote:
>> Thank you very much for the fast reply.
>>
We are building a new system that will support a large number of users
>>
(high volume, high concurrent usage, etc). We have play
Am 21.06.2012 22:22, schrieb Timo Sirainen:
> On Thu, 2012-06-21 at 13:05 -0700, email builder wrote:
>> Do you know what webmails are caching vs. non-caching?
>
> Nearly all of them are non-caching. (I don't know of any caching ones.)
At least roundcube (v0.7.1 here) has some caching options:
Am 21.06.2012 22:22, schrieb Timo Sirainen:
>> Do you know what webmails are caching vs. non-caching?
>
> Nearly all of them are non-caching. (I don't know of any caching ones.)
roundcube can if configured
additionally you should install imapproxy on the webserver
wehre your webmail is runni
On Thu, 2012-06-21 at 13:05 -0700, email builder wrote:
> Thank you very much for the fast reply.
>
> >> We are building a new system that will support a large number of users
>
> >> (high volume, high concurrent usage, etc). We have played with Dovecot,
> >> but in
> >> most serious applica
Thank you very much for the fast reply.
>> We are building a new system that will support a large number of users
>> (high volume, high concurrent usage, etc). We have played with Dovecot, but
>> in
>> most serious applications we have traditionally used Courier IMAP. It's my
>> (lay) unde
On 21.6.2012, at 21.05, email builder wrote:
> We are building a new system that will support a large number of users (high
> volume, high concurrent usage, etc). We have played with Dovecot, but in
> most serious applications we have traditionally used Courier IMAP. It's my
> (lay) understan
36 matches
Mail list logo
