Re: [Mailman-Developers] Future of pipermail?
"BAW" == Barry A Warsaw barry@digicool.com writes: "GE" == Gunnar Evermann ge204@eng.cam.ac.uk writes:
GE> What are the current plans about the html archiver in mailman?
GE> The major shortcomings of pipermail I see are:
| - doesn't decode MIME
| - doesn't handle mixed charsets
| - no search engine
| - somewhat convoluted code.
The last is the killer, because it makes the first three that much harder to accomplish. I tried some refactoring for the 2.0 release, but I'm not convinced there is much worth saving.
BAW> Anyway, yes, we'd like to rewrite the archiver from the ground BAW> up, but nobody's working on that yet. I suspect either Jeremy BAW> or I will tackle it at some point.
It's not near the top of my priorities at the moment, but I would like to work on a new archiver. Perhaps we should start sketching some design issues in Barry's Mailman wiki.
I would also like to see separation of the presentation part of the archive from the code, so that it is easier to customize the presentation.
Jeremy
At 9:41 PM -0500 11/16/00, Jeremy Hylton wrote:
It's not near the top of my priorities at the moment, but I would like to work on a new archiver. Perhaps we should start sketching some design issues in Barry's Mailman wiki.
Does mailman have to an an integrated archiver? Isn't this another variant of the "integrated MTA" discussion?
I'd prefer, honestly, splitting out pipermail (or it's successor) into a separately tracked project, and building a standard interface that will work with it and with other archivers, like Mhonarc. That way, a separate team can be built to work on Pipermail, and releases of each piece don't have to be wedged into the same schedule, and you simplify the complexity of each project to improve focus....
"CVR" == Chuq Von Rospach chuqui@plaidworks.com writes:
CVR> Does mailman have to an an integrated archiver? Isn't this
CVR> another variant of the "integrated MTA" discussion?
CVR> I'd prefer, honestly, splitting out pipermail (or it's
CVR> successor) into a separately tracked project, and building a
CVR> standard interface that will work with it and with other
CVR> archivers, like Mhonarc. That way, a separate team can be
CVR> built to work on Pipermail, and releases of each piece don't
CVR> have to be wedged into the same schedule, and you simplify
CVR> the complexity of each project to improve focus....
This could probably work.
I do want an archiver that I can bundle with releases (let's say final releases primarily) because it's just so much easier for newbies to get started if they have everything they need. They already have the burden of having to download and install Python (and maybe a web server and an MTA), so reducing the number of components you need to get started is a good thing. For all it's flaws, Pipermail provides an essential service with no extra work (it'd be nice to also have a bundled search solution).
OTOH, I think we can handle it similar to the way Python does it's rpms or windows installers and add-ons like readline and Tk. We find a stable version of the archiver and bundle it in the big releases, but beta users may have to do more work.
"NM" == Nigel Metheringham Nigel.Metheringham@VData.co.uk writes:
NM> Maybe. There are times when I would really love to have
NM> archive message id or URL references in messages for example -
CVR> But does that imply it has to be integrated into mailman? Or
CVR> just available.
CVR> The only reason I see for it to be fully integrated is if we
CVR> want to add a header pointing to the article in the archive
CVR> -- that would require archive processing during
CVR> delivery.
Maybe not, if we define an API that Mailman can ask the archiver, "give me a url for message-id XYZ".
-Barry
Continuing the thoughts on integration or separation of archiver functions... heres a flow of my ideal wrt to archiving and MIME processing of list messages:-
Message received by mailman
Policy decisions applied to message (ie accept, bounce, moderate) depending on things such as sender/recipient/list policy/MIME etc
Message archived. MIME attachments/portions split into separate retrievable sections. The archived MIME sections become available to latter processes as retrieval URLs. Overall Message ref also available to all subsequent processes (ie as additional header with this message archive URL)
Send out process set. This would allow, for example:-
- some recipients to receive original MIME encoded message
- some recipients to receive simplified message with limited MIME (maybe just text/plain) plus URLs
- some receive text/plain version as a digest
The send out messages would depend on a combination of list and personal policy - ie some people could be on a MIME accepting list, but prefer simplified mail. Or the list could mandate no transmitted MIME. The original policy set could also just block MIME or large MIME.
However this is just one way things could work... I just get this feeling that archiving and MIME stripping can be closely related...
Nigel.
"NM" == Nigel Metheringham Nigel.Metheringham@VData.co.uk writes:
NM> Continuing the thoughts on integration or separation of
NM> archiver functions... heres a flow of my ideal wrt to
NM> archiving and MIME processing of list messages:-
Good points Nigel. I've added some of these to the FutureOfPipermail Wiki.
NM> However this is just one way things could work... I just get
NM> this feeling that archiving and MIME stripping can be closely
NM> related...
Very possibly so. Having a general repository for messages and their MIME parts might be a good thing. I'm a little worried that we might be giving up independence and plugability, since I don't know whether any of the other 3rd party archivers support such features.
-Barry
At 11:52 AM -0500 11/21/00, Barry A. Warsaw wrote:
Very possibly so. Having a general repository for messages and their MIME parts might be a good thing. I'm a little worried that we might be giving up independence and plugability, since I don't know whether any of the other 3rd party archivers support such features.
some do. Maybe the answer is to allow the API to configure how the archiver wants it, so we can have mailman strip it to a text-only part if the archiver wants it that way.
sorry for the delay. we went to Portland for our annual fall trip, and to be honest, I didn't turn on a computer the whole trip (and the world didn't end, either. amazing...)
I do want an archiver that I can bundle with releases (let's say final releases primarily) because it's just so much easier for newbies to get started if they have everything they need.
fair point, one I've sort of ignored. In theory, I'd prefer a situation where we simply included a "turnkey" set of instructions for a preferred archiver, but in practice -- that theory doesn't work as well...
They already have the burden of having to download and install Python (and maybe a web server and an MTA), so reducing the number of components you need to get started is a good thing.
true. Or maybe the answer is some kind of meta-setup beast like some folks use for Apache? Or does that just add complexity without solving anything?
I'm brainstorming -- not pretending to answers, but asking questions that'll help us understand where the answers ought to be...
Maybe not, if we define an API that Mailman can ask the archiver, "give me a url for message-id XYZ".
man, I can be such a luddite some daays. I insist on thinking about APIs as hand-off interfaces, not bi-directional. Of course data can go both ways, although if you want to plug in an external archiver, the API has to be smart enough to return some kind of not-supported value (or preferably, a flag that can be queried during web-page creation as to whether or not ot show the option....)
"CVR" == Chuq Von Rospach chuqui@plaidworks.com writes:
CVR> true. Or maybe the answer is some kind of meta-setup beast
CVR> like some folks use for Apache? Or does that just add
CVR> complexity without solving anything?
There's something in Python called `distutils' which is a way to distribute and build extensions to Python. I don't think distutils currently works well for applications, but that might be a direction to explore.
Distutils will likely be the underlying technology for a Pythonic CPAN like thing that everyone's been pining for but few have had the time to pursue.
One nice thing about distutils is that it makes the building of extension modules completely trivial. I have a couple of nice (optional) performance improvements written in C for Mailman 2.1 which are easily built and installed with a distutils `setup.py' script.
-Barry
participants (4)
-
barry＠digicool.com -
Chuq Von Rospach -
Jeremy Hylton -
Nigel Metheringham