[Mailman-Developers] Future of pipermail?

[Chuq Von Rospach]

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