[XML-SIG] Re: Maki: great!

Alessandro Bottoni abottoni@quadrante.com
Thu, 21 Feb 2002 11:14:30 +0100


See below...
----- Original Message -----
From: "Nicolas Chauvat" <Nicolas.Chauvat@logilab.fr>
To: "Alessandro Bottoni" <abottoni@quadrante.com>
Cc: <xml-sig@python.org>
Sent: Wednesday, February 20, 2002 5:01 PM
Subject: Re: [XML-SIG] Re: Maki: great!


> > [Alessandro Bottoni] I can just speak for myself but I think that Maki
> > is already giving us what we actually need: a robust, elegant, modular
> > system that we can use as a skeleton for developing a full-blown
> > portal system like "Cocoon portal", PHPNuke, ezPublish and so on. If
> > we can leave most of the "general purpose" tasks (XML/XSLT management,
> > session management, DB abstraction layer, etc...) to Maki, we can
> > focus on creating task-specific "modules" (article publishing, poll
> > management, calendar, etc...) that will eventually sum up to a real,
> > full-featured portal system. That would be a really great achievement,
> > in my opinion.
>
> Others have been there already. Look at Zope (Portal, components, etc.)
> and 4SuiteServer. Setting up a portal, integrating services, metadata,
> databases, etc. everything is there.

[Alessandro Bottoni]
Mmmmhhh..... interesting but....

Zope:
I tried it a year or two ago. I abandoned it for these reasons:
1) The existing documentation was scarce and not very clear. I had to figure
out how to use, configure and extend the system by trial and error. I had a
hard time trying to understand the whole architecture of Zope and its "nuts
and bolts". For sure, the current situation is much better.
2) You have to use its UI to create a site, configure and manage it. I was
unable to find a way for creating pages, configuring the system and manage
it with external programs/scripts or with external tools. In my production
environment, it is not very realistic that every single operation on the
system has to be performed by hand.
3) The OODB behind Zope is quite an obscure object and I found impossible to
access it in any other way than using the supplied Zope GUI. That is quite
limitating. Think to a massive "import" from an external data source.
4) The Zope architecture is quite monolithic. I was unable to understand how
to extend it and how to create task-specific modules, probably and partially
because of the scarce documentation. I'm sure the situation is much better
now (You mentioned "components"...).
Frankly, I will not give a second glance to Zope after this experience.
There is better stuff out there, IMHO.

4SuiteServer
1) 4SuiteServer is a commercial application. When possible, I (we) avoid to
use commercial application, even if the cost is very, very low. The reason
of this (arguable) behavior is that is becoming a nightmare to manage the
huge amount of license documents/criteria and the continuos stream of
licence expiration/payment events in our (already chaotic) production
environment. For what regards me, I abandoned M$ for the same reasons a long
time ago.

What I really need, is an open source, modular, easily configurable, easily
extendable, pre-built portal. Something I can install in a couple of hour,
prepare it for the customer in a couple of days and manage from script and
external tools at my wish. Something that makes easy to create task-specific
modules and that can accept new modules in a easy way. That is exactly what
ezPublih gives me in the HTML field. That is what "Cocoon portal" promises
in the XML arena. As long as I can see, nothing like that is available in
the Python world, at the moment.

In any case, thanks for the information.

>
> --
> Nicolas Chauvat
>
> http://www.logilab.com - "Mais oł est donc Ornicar ?" - LOGILAB, Paris
(France)
>
>