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....)
-- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com)
The vet said it was behavioral, but I prefer to think of it as genetic. It cuts down on the liability -- Get Fuzzy