pan-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pan-users] "Automatic" unsubscription (bug?)


From: Duncan
Subject: Re: [Pan-users] "Automatic" unsubscription (bug?)
Date: Fri, 16 May 2003 08:57:04 -0700
User-agent: KMail/1.5.1

On Fri 16 May 2003 06:10, Frank Van Damme posted as excerpted below:
> On Thursday 15 May 2003 05:13, Duncan wrote:
> > I'm in favor of keeping the maildir format, simply because it tends to be
> > a bit more resistant to corruption.
>
> Not to mention performance.
>
> > However, it does need modified to keep
> > the number of files in an individual dir down to some reasonable number.
>
> You mean below one million in a single dir? :-)

Perhaps something like the IE cache thing may be useful.  MS split the cache 
into several subdirs, altho it all showed up as a single virtual folder, due 
to the magic of system folders in Explorer.  The main cache dir simply had an 
index file and four initial data subdirs, with the data round-robin-ed (I 
think) between them.  Once the cache got over a certain size, more were 
added, keeping the number of individual files per dir to a level where 
performance wasn't severely affected.

Of course, IE always DID have cache management issues.  Back when I 
participated in the IE betas (4-5.5, by 6.0, I was to busy preparing to 
switch to Linux to worry about running a beta on what was a dead-end OS for 
me), at least half of us regulars in the msie newsgroups ran David Pochron's 
Cache Sentry.  It was far more effective at properly managing the IE cache 
than IE itself was, and we found it ironic that all the MS programmers 
couldn't figure out how to do it as well as some guy doing it in his free 
time and releasing his manager for free.  I suppose that was one of my first 
illustrations of the principles of open source, as on a software Libre 
platform, I'm sure it would have been integrated into the main product.  We 
never COULD figure out why they didn't just hire him or license his 
management technology and be done with it.  By 6.0, they FINALLY had most of 
it right, I think.  5.5 corrected most of the worst initial problems, but a 
few weird corner cases remained.

Anyway, I really doubt we will have a lot of action on that until the backend 
db management rewrite.  It just isn't worth messing with what's working 
fairly decently now, for what amounts to a temporary fix, as it would be 
redone with the introduction of the SQLite libs for the db handling anyway.

-- 
Duncan
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin





reply via email to

[Prev in Thread] Current Thread [Next in Thread]