On Sun, 09 Dec 2001 19:48:56 -0600 Stephan Richter <[EMAIL PROTECTED]> wrote: > At 05:02 PM 12/9/2001 -0800, J C Lawrence wrote: >> On Sun, 09 Dec 2001 16:34:53 -0800 Dan Mick >> <[EMAIL PROTECTED]> 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. [EMAIL PROTECTED] He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. _______________________________________________ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
