[Mailman-Developers] Future of pipermail?
Chuq Von Rospach
Mon, 20 Nov 2000 21:41:51 -0800
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
> 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
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:email@example.com)
Apple Mail List Gnome (mailto:firstname.lastname@example.org)
The vet said it was behavioral, but I prefer to think of it as genetic.
It cuts down on the liability -- Get Fuzzy