Vladimir Marek writes:
> Well, if your granularity will be one archive per year of mail, it
> should not be that bad ...
Except for someone like Keith, who has all his email since sometime in
the 80s or something insane like that :)
--
Stewart Smith
pgpqbDWUxd3Kw.pgp
Description: PGP signatur
On Tue, Aug 14, 2012 at 8:11 PM, Christophe-Marie Duquesne wrote:
> one could complete this work with an
> interface to couchdb for offlineimap
*I meant for notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo
On Tue, Aug 14, 2012 at 7:05 PM, Ciprian Dorin Craciun
wrote:
> I proposed -- better said queried if possible or at least wanted
> -- to have an internal interface (SPI) that any mail store would have
> to implement in order to be indexed and used by notmuch. I guess the
> interface would be q
On Tue, Aug 14, 2012 at 7:50 PM, Vladimir Marek
wrote:
>> On the other hand I strongly sustain having a more optimized
>> backend for emails, especially for such cases. For example a
>> BerkeleyDB would perfectly fit such a use case, especially if we store
>> the body and the headers in separa
> >> > - fuse zip stores all changes in memory until unmounted
> >> > - fuse zip (and libzip for that matter) creates new temporary file when
> >> >updating archive, which takes considerable time when the archive is
> >> >very big.
> >>
> >> This isn't much of a hastle if you have maildir
On Tue, Aug 14, 2012 at 7:04 PM, Vladimir Marek
wrote:
>> > - fuse zip stores all changes in memory until unmounted
>> > - fuse zip (and libzip for that matter) creates new temporary file when
>> >updating archive, which takes considerable time when the archive is
>> >very big.
>>
>> Thi
> > - fuse zip stores all changes in memory until unmounted
> > - fuse zip (and libzip for that matter) creates new temporary file when
> >updating archive, which takes considerable time when the archive is
> >very big.
>
> This isn't much of a hastle if you have maildir per time period
Vladimir Marek writes:
> Hi,
>
> I have objections against maildir too, but I tried to tackle it from
> different perspective. Store the maildir in zip file and use fuse-zip to
> manage it. It works sort of but it has two major disadvantages:
huh... this is fairly interesting one of the downs
On Sat, Aug 11, 2012 at 11:50 PM, Jameson Graef Rollins
wrote:
> On Sat, Aug 11 2012, Ciprian Dorin Craciun wrote:
>> My problem with it is that it doesn't scale... And I don't mean
>> this in a theoretical sense, I mean it in the concrete one: I have
>> about 661k emails... And a single `not
On Sat, Aug 11 2012, Ciprian Dorin Craciun wrote:
> My problem with it is that it doesn't scale... And I don't mean
> this in a theoretical sense, I mean it in the concrete one: I have
> about 661k emails... And a single `notmuch sync` takes a few tens of
> seconds...
Hey, Ciprian. That soun
Ciprian Dorin Craciun writes:
> My question -- rather a curiosity -- is if one could easily
> implement an alternative message store instead of maildir. (I actuall
y
> have in mind a KV store like BerkeleyDB, or even a database like
> CouchDB...)
See
id:"1340657517-6539-6-git-send-emai
How about implementing MIX[1]
(and yes, i am totally ignorant about the format, i just know of it, and have
heard some praise).
[1] http://en.wikipedia.org/wiki/MIX_(Email)
--
m...@pels.in
(sorry about top posting, the mailclient on nokia n9 truly sucks.)On 2012-08-11
09:35 Ciprian Dorin Crac
On Sat, Aug 11, 2012 at 12:46 PM, Vladimir Marek
wrote:
> Hi,
>
> I have objections against maildir too,
Just for the record I have nothing against maildir (or at least
when compared to mbox format). On the contrary I find it quite easy to
fiddle with...
My problem with it is that it doe
Hi,
I have objections against maildir too, but I tried to tackle it from
different perspective. Store the maildir in zip file and use fuse-zip to
manage it. It works sort of but it has two major disadvantages:
- fuse zip stores all changes in memory until unmounted
- fuse zip (and libzip for th
14 matches
Mail list logo
