[Mailman-Developers] ZMailman 2.1 preview

[J C Lawrence]

On Sun, 09 Dec 2001 19:48:56 -0600 
Stephan Richter <srichter@cbu.edu> wrote:
> At 05:02 PM 12/9/2001 -0800, J C Lawrence wrote:
>> On Sun, 09 Dec 2001 16:34:53 -0800 Dan Mick
>> <dmick@utopia.West.Sun.COM> wrote:

>>> I don't understand Zope; can someone describe why I might want
>>> this, what it buys me, etc. (like a sales brochure)?
 
>> Think a semi-OO based PHP setup where the OO as[ects extended not
>> only to the internal language, but also to the construction of
>> page elements and templates, and of course, instead of using PHP,
>> use Python and much more cleanly abstracted DB interface.
>> Probably the biggest other difference is that Zope natievly works
>> off a single unified store rather than the filesystem.

> Yes, that is pretty good, even though comparing Zope/Python to PHP
> is not really possible.

True, but for a generally non-Web person (into which camp I believe
Dan falls), I felt it was a reasonable give-him-a-basic-grok
description.  As with all such generalities, it suffers in the
details.

> First of all, the Python team and the Zope team work all for the
> same company Zope Corp.

Which doesn't really affect the definition of Zope as a product much
at all, but whatever.

> If you like Python and need to do Web applications a lot, you
> should have a look at Zope (www.zope.org). It is a very nice
> software and does a lot of things for you.

Aye, Zope is a nice system.  I spent quite a while looking at it for
what I want to do before finally backing away.  Its not that Zope
was bad or inadequate, just that I want to take a much more laissez
faire approach to inter component and system integration that Zope
(at that time) would seem to encourage.  (Things may have changed)

> Furthermore, for the Mailman 3.0 release I would like to make a
> case for using the ZODB (not the entire Zope package!) for storing
> our data structures, since we will not have to worry about file
> locking and data storage in general anymore. 

There's some good reason for this, but I suspect a better case could
be made for moving to an even more platform and tool agnostic data
storage system, making Mailman that much easier to integrate and tie
in with other systems without having to add plugins, adaptors, or
other potential-source-of-failure fiddly bits in the picture.

I know Barry is excited by the ZODB prospect.  <shrug>  

> As you might have noticed, this is really what I am interested in,
> because having tighter integrations between Web tools and Mailman,
> could give Mailman a huge boost in usage. 

We should be careful over the distinction between "tighter
integration with Zope" and "tighter integration with web tools".
The two don't necessarily have to be different, and much of the work
for Zope integration lends itself well to general integration, but I
would like to see the interfaces there be kept extremely abstract
and local system independent.

Ever thought about queue manipulation and injection by external
tools and processes?  It gets really interesting once you start
messing with very large mail systems or systems ala Chuq's.  but,
I've commented on this previously, its all in the archives (mostly
in the early 2.1/3.0 design discussions between Chug, Barry, Nigel,
(some others I shamefully forget) and myself) so I'll leave this
here.

> In fact, the current ZMailman release does already some nice
> things, but it will be even better, once the data is stored in the
> ZODB.

Would making the ZODB transition also make it easier to move to
LDAP?  SQL?  ODBC?  XML/RPC?  SOAP?  Driving Mailman from an
external queue processing system ala (eg) MQS?  Those are the sorts
of generic integrative data access things I'm interested in.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
claw@kanga.nu               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.