Re: mailing list archiver chewing patches - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: mailing list archiver chewing patches
Date
Msg-id 9837222c1001110146o36e5507eqa7096ea3687e54bc@mail.gmail.com
Whole thread Raw
In response to Re: mailing list archiver chewing patches  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: mailing list archiver chewing patches  (Dimitri Fontaine <dfontaine@hi-media.com>)
Re: mailing list archiver chewing patches  (Abhijit Menon-Sen <ams@toroid.org>)
List pgsql-hackers
2010/1/11 Alvaro Herrera <alvherre@commandprompt.com>:
> Dimitri Fontaine wrote:
>> Andrew Dunstan <andrew@dunslane.net> writes:
>> > That is assuming that the MUA gives you the option of specifying the
>> > attachment MIME type. Many (including mine) do not. It would mean an extra
>> > step - I'd have to gzip each patch or something like that. That would be
>> > unfortunate,as well as imposing extra effort, because it would make the
>> > patch not display inline in many MUAs (again, like mine).
>>
>> Bad MUA, change MUA, or what they say…
>>
>> More seriously though, it's not the first time we're having some
>> difficulties with the MHonArc setup, and I think it's also related to
>> the poor thread following on the archives website at month boundaries.
>
> Absolutely.  The month boundary problem boils down to the fact that
> Mhonarc does not scale very well, so we can't have mboxes that are too
> large.  This is why most people split their archives per month, and then
> each month is published as an independent Mhonarc output archive.  It's
> a horrid solution.

Yeah.


>> Are our indexing and searches provided by MHonArc or maintained by the
>> community?
>
> Searches are completely external to mhonarc.

It is, but it's tied into the format of the URLs and the format of the
actual messages in order to be more efficient. But it should be fairly
easy to adapt it to some other base system if we want.


>> How helpful considering alternatives, such as AOX (which runs
>> atop PostgreSQL and would offer anonymous IMAP facility over the
>> archives) would be?
>>
>> Of course it'll boil down to who's maintaining the current solution and
>> how much time is allocated to this, the solution research and migration
>> would have to fit in there I suppose. Same as pgfoundry. But still,
>> should we talk about it?
>
> There's some talk about writing our own archiving system,
> database-backed.  There have been a few false starts but no concrete
> result so far.  We need a lot more manpower invested in this problem.
> If there's interest, let's talk about it.

Yeah, definitely, let's talk about it. Anything that gives us an
efficient backend with a good API is interesting (SQL is a reasonably
good API. Not so sure about IMAP, since it is a bit too focused on
single messages IIRC). Particularly, something that can separate
frontend and backend (can still be on the same machine of course, I'm
talking conceptually) seems to be a lot more flexible, which we'd
like.

As for AOX, my understanding is that it is no longer maintained, so
I'd be worried about choosing such a solution for a complex problem.
But it's open for discussion.


-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/


pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Testing with concurrent sessions
Next
From: Arnaud Betremieux
Date:
Subject: Re: Listen / Notify - what to do when the queue is full