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.