[prev in list] [next in list] [prev in thread] [next in thread] 

List:       perl-mailbox
Subject:    Re: Compressed Mail Archives
From:       Melvyn Sopacua <msopacua () idg ! nl>
Date:       2002-10-26 14:33:47
[Download RAW message or body]

At 13:31 23-10-2002, Elizabeth Mattijsen wrote:

>At 08:24 PM 10/22/02 +0200, Melvyn Sopacua wrote:
>>>To extend the debate a little.  I would like to have an extension which
>>>could maintain a composed folder, where old messages are archived, and
>>>new messages are still accessable fast.
>
>What would be against creating an archive mailbox format that would be 
>specific to Mail::Box only?  With Mail::Box's API you should be able to 
>move messages semi-automatically from one mail-box (format) to another 
>(format).  You would basically use the current API, you wouldn't need to 
>create a new one.  Archiving would be moving to such an archive-format 
>mailbox, un-archiving moving it back to a "standard" mailbox format.

Choice really. But depends on the extensibility of the Archive formats. 
Especially with archives I like the idea of handlers as archivers. It 
doesn't matter then what the actual storage is. For example using libcurl ( 
http://curl.haxx.se ) remote storage basically requires a url and the 
content, while a large number of protocols is available. It would be just 
as easy, to feed the wordcounts to a database or xmlrpc service, whatever 
your flavour of the day is :).

>>But the main issue is to split this up in reasons for compression:
>>-- An online system, which is trying to save storage space compression 
>>rate is as important
>>     as the decompression speed. Depending on the user's preference, this 
>> would result in 2
>>     major implementations:
>>     1) 'Current' is uncompressed, messages should be 'marked for 
>> archiving' or a rotation
>>         scheme is chosen based on arrival time.
>>     2) New mail is uncompressed to facilitate faster SMTP delivery, read 
>> mail is compressed.
>
>I would see this funtionality to be developed on top of the current API, 
>not as part of the current API.  It's just too difficult to get it right 
>for everybody.

+1

>If you're looking at searching, NexTrieve (http://www.nextrieve.com) 
>already supports Mail::Box (through the NexTrieve::Message module, which 
>takes Mail::Box::Message objects on input).

I'll do that (last time was about 6 months ago, so would like to see what 
you been up to :).



Met vriendelijke groeten / With kind regards,

Webmaster IDG.nl
Melvyn Sopacua


[prev in list] [next in list] [prev in thread] [next in thread]