Re: mailing list archiver chewing patches

2010/1/11 Alvaro Herrera <alvherre(at)commandprompt(dot)com>:
> Dimitri Fontaine wrote:
>> Andrew Dunstan <andrew(at)dunslane(dot)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 Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/