Re: eZ in Debian-Edu and on skolelinux.org?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 17-01-2005 13:29, Alex Brasetvik wrote:
> Markus Gamenius has been in contact with the guys behind eZ [1]. They
> are apparently eager to get eZ into Debian-Edu and to help us convert
> from Plone [2] on www.skolelinux.org.
>
> There are currently (at least) two issues with Plone on skolelinux.org.
> One being the workflow (have to use the webpage, no automatic
> notifications about translations, etc.) and a memory leak in Zope which
> makes it necessary to restart Zope every few weeks.
>
> The debate started on the Norwegian user list, but we feel our
> international collegues need to join in. :) I just moved the debate, so
> this post won't contain my opinions.
>
> ~
>
> Do we want to change Plone for X on skolelinux.org? Might X be eZ?
>
> Do we want to bundle eZ as Debian-Edu's content management system (CMS)?
> What issues need to be solved?
>
> Is it necessary to use the same CMS we bundle in Debian-Edu, e.g. eZ, on
> skolelinux.org? If not, is a Wiki[3] a good idea? Combinations?
It may be interesting to switch from Plone, but not because of memory
leaks: they were (on the norwegian list) told to be worked around by
restarting the server regularly, and when solved should be fixable by
simply updating the Debian package without touching the content at all.
That, I believe, is not possible currently with an EZ-based site.
Reasons for choosing site engine (were I see "CMS" as being one group of
engines and "Wiki" another one) are these, IMHO:
Access
======
Classic CMS gives central control of what gets published where and when.
Wiki gives public access to publish anything anywhere.
Those are extreme opposites of each other.
Some wikis support Access Control Lists that breaks the original "pure"
wiki idea and may satisfy the needs of some needs for control - but
probably not if control is of major concern.
On the other hand do some classical CMS provide wiki as add-ons, thus
providing a "speakers' corner" in the generally controlled environment.
Similarly that probably won't satisfy the most freedom-hungry.
As I see it, the skolelinux organisation want the freedom, while the
needs of most schools is central control.
Task interaction
================
The Debian website is pretty complex to maintain. The reason is that the
tasks of design, publishing and translation are so big that each of them
needs separate groups of people. Translators need (almost) only to deal
with standard locale files known from translating software, and web
mirrors need only deal with static files copied from a central ftp or
rsync source. In other words, tasks are doable without the need of each
other - and can even be done "offline", only requiring a sync now and then.
Most CMS are invented with the _purpose_ of tightly integrating the
different tasks, so that everything is managed from the same (usually
web-based) administrative interface.
If Skolelinux is aiming at adoption into Debian (which I am _not_
arguing for or against here!) or seek similar goals (ease of translation
and mirrored publishing) then neither CMS nor Wiki is the way to go -
instead I recommend using the same approach as Debian - and I offer my
help in doing so (my own main website has used same engine for a couple
of years, tweaked to store content more natural instead of as html).
If Skolelinux instead favor ease of publishing from all participants of
the project, then I recommend using a Wiki.
If Skolelinux wants a central control of the content of the site and at
the same time ease of administration, then a CMS is the way to go.
CMS engines
===========
Plone is based on Zope. It seems to have not been working properly with
Woody, but stabilizing with Sarge. Remember to judge the stability of
Plone separately from the stability of Plone running on a "more-ore-less
Debian" system. The use of backported packages may play a big role in
the stability of the complex environment behind Plone.
EZ-Publish is based on PHP. PHP has been in Debian for quite long, and
is stable, also in Woody.
Some critisize PHP as being too big: too much potential for security
flaws waiting to be found. I do not know if PHP is worse than Zope...
I maintain the CMS-engine EZ-Publish 2.x officially for Debian.
EZ-Publish 2.x is no longer maintained upstream, and there's rumors it
was sold to another company that may take over maintaining it.
EZ-Publish 3.x and newer is _different_ from EZ-Publish 2.x, and not
currently packaged for Debian. I may possibly be interested in
maintaining a Debian package - but please read below about distributed
maintainance of web engines.
Wiki engines
============
Lots and lots of wiki engines exist, each with different advantages and
goals.
Probably the most famous wiki is http://www.wikipedia.org/ - it uses
(more or less) MediaWiki as engine.
I maintain the wiki-engine MoinMoin officially as Debian package
(package-name "moin").
Distributed maintainance of web engines
=======================================
A Linux distribution contains static, tweakable and variable stuff.
Stuff packaged as Debian packages are "owned" by the Debian system, and
when Debian packages are updated that stuff is replaced with the stuff
contained in the newer package. From a local administrators point of
view this stuff is static.
An exception to this is "conffiles" that are installed by the packages
(mostly below /etc ) but intended for the local administrator to tweak
as needed.
Stuff below /var is "variable" - either directly by the local admin or
indirectly by the programs running on the machine. Some of it is
generated at install time of some package, but a package is not allowed
to simply replace it later on, as it may since be changed locally by the
administrator of the machine.
So what has all this to do with web engines like CMS and Wiki?
Well, a CMS like EZ-Publish 2.x has visual design and business logic all
within the same (thousands of) PHP files, making it virtually impossible
to separate them so that visual design can be adjusted or replaced
locally while the business logic is still maintainable by the packaging
routines.
Some web engines do it right. A quick look at an engine mentioned on the
norwegian Skolelinux list today, moodle, seems to show a good example
were admin.tweakable parts of the system is stored in an SQL database so
that the PHP-based business logic can be placed below /usr/share (were
only static files are allowed).
Other engines don't do it right - or the maintainer is not aware of
setting it up maintainable. If you favourite Debian package throws stuff
below /var/www then consider this: who is supposed to maintain it in the
future: you or the package maintainer?
Zope stores all content in a Zope database, so does it right.
With EZ-Publish 2.x I have more or less given up on separating stuff,
and instead the package provides admin-maintainable stuff. I do not
believe it possible to do it differently. If you disagree, I welcome
suggestions: File a wishlist bugreport to the package!
EZ-Publish 3.x is a complete rewrite with multi-layered business logic
and visual design separated. I tried but failed using the separation to
install business logic and visual layout separately. I may be interested
in maintaining the package if this is possible - if not then I am too
sick and tired of messing around with the thousands of PHP files.
With MoinMoin I do somewhat similar currently: The business logic is
nicely seperated from content, but documentation is provided as wiki
pages and can't be maintained witout interfering with the local content.
Newest release of MoinMoin is currently being packaged, and resolves
this: content is "layered" so that additional pools of non-editable
files can be included below the editable ones (i say "below" because if
non-editable files are edited then they are simply mirrored to the top
layer and edited there).
Hope I made myself clear.
- Jonas
- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
- Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB69fGn7DbMsAkQLgRAuJIAJ0Rw8KrQInvViM51cDdVwPCD5lBYgCfULkB
zZB4fOfu3KpeOW9M0NaS3LI=
=Foc6
-----END PGP SIGNATURE-----
Reply to: