[Mailman-Developers] Re: Future of pipermail?

[Chuq Von Rospach]

At 4:29 PM -0800 11/21/00, J C Lawrence wrote:

>For me WebDAV raises concerns centering around authentication and
>access security.

Authentication is a big bugaboo in general, which Barry and I have 
hashed around a bit. More on that someday, maybe.

>   That said, I fail to see either the use or value
>in having what is essentially (if I understand it correctly) a
>posting tool (ability to post content to a site) *UNLESS* the
>archiver is running on a different machine than Mailman (in which
>case a networked filesystem would seem a safer/lighter approach).

Well.... it comes down to two key terms: The "C" word and the "I" word.

Convergence and Integration.

There are fewer and fewer sites that "run mailing lists" -- and more 
and more sites that have mailing lists as part of a larger 
site/strategy. all of these technologies are converging as people 
figure out they can be used together to complement each other -- and 
that convergence is creating a severe need to integrate them to keep 
them usable (and preferably, easy to use) for the end user.

Take my sites as examples ---  www.hockeyfanz.com. Apache web server, 
mwforum for web discussion (nad my list directories), mailman for 
lists, htdig for search engine (soon), mhonarc for archives, ircu for 
real time (soon). The forum has a separate authentication from the 
lists, and the archives have their own password (although I've 
figured out how to write an apache authentication module as a hack, 
so I can use mailman info instead -- someday). the forums have a 
different search engine than the archives will.

So to fully use the system, there are two places to register/login, a 
third password for archives (each list has its own password, 
remember), and two search engines, depending on whether you want list 
to search the forum or mail lists. And this is after I've worked my 
butt off to find stuff that integrates as well as I can. It's about 
as close to state of the art as possible (IMHO), in terms of the 
technologies I need.

The biggest problem I have? user confusion -- can you blame them? I 
understand all of these pieces, but why should they? Answer: they 
shouldn't.

I have a site. My user should have a way to register and use it. 
Which piece registers what way shouldn't matter based on phase of the 
moon....

So for me, integration and convergence is a Big Issue. I have Ideas 
On How To Do this, as Barry knows, but nothing we've taken public 
yet. But this is the next big phase of this stuff. Not making it 
work, making it work TOGETHER.

And as we figure out how to make it work together, we can't throw out 
the people who just want to run a couple of mail lists. And *that* is 
the problem with Zope, or WebDAV, or name your favorite integration 
tool - because the more you depend on that stuff, the harder it is to 
just use the tool itself. It has to be a floor wax and a dessert 
topping.

Which is very possible. Ca be done, but not easy. But worth doing. 
All of these things are converging, and to do so succeesfully, we 
have to integrate. But we need to integrate in ways that are modular 
with standard interfaces, so that we don't require someone install 
200K lines of code to get a stupid mail list running for their bridge 
club....

So tools like Zope, or WebDAV, or Mhonarc, or even Pipermail are 
important things to consider, support and perhaps use, but we have to 
be hugely careful about requiring the use of things, while enabling 
them to be used. The fewer things you force someone to use, the 
better off we are: but the more things wee *can* work with, the 
better off we'll be.

(and the other cool feature is that if we avoid reinventing stuff, 
but instead write interfaces to them, we leverage off a lot more work 
of a lot more people, because writing an glue interface to mhonarc is 
a LOT faster and easier than writing Mhonarc. writing a glue 
interface to HtDig is a LOT faster and easier thanw riting HtDig. And 
if someone doesn't want Mhonarc or HtDig, they can simply write their 
own interface to their own tool, and (hopefully) submit it back to 
the project so we can all benefit....THAT is, IMHO, the strongest 
argument against integrating stuff like Pipermail into the project 
itself -- it requires owrk that can go into core functionality 
instead, and it also discourages people from building or interfacing 
other technologies, because we've "defined" the default. That's why I 
think running Pipermail as a separate project, and writing the 
interface glue so that it's supported by Mailman "out of the box" is 
a better idea than rnning them as the same project -- they're 
separate code pieces with a common interface that really odn't have 
anything in common, and I think it discourages integration of other 
pieces.

There are things that are core functionality for mailman: subscriber 
services, delivering mail. There are core technologies that Mailman 
needs, like archives and search engines (if you want to have 
integrated archives, you have to have search capabilities), but 
services like that are probably better handled via interface glues. 
Tehy don't need to ship with the core code, but instead, you ship the 
interface and instructions on getting it installed and running. it 
can still be the 'official' or 'default' tools, but they don't need 
to be IN the distribution, especially if they're things people might 
or might not use.

Actually, *everything* ought to be defined with a formal API that can 
be replaced with a different plug-in if someone wants to (at least as 
a long-term goal), but some stuff is appropriate to be *in* the 
distribution, and some interfaced to by the distribution. And which 
is which is part of the architecting process. But given that we're no 
longer in a "alone in the world" environment, we have to stop 
thinking in terms of doing it all ourselves.



-- 
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