[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On Tuesday 15 February 2005 6:34 pm, Matt Lee wrote:
The data file can be squashed down, and it while I believe it can be a little tricky at times to shift the Data.fs between systems, it can be done.
That's not what is claimed, Plone claims that copying the file is trivial - it is not.
Of course, your testing system should be identical to your deployment system anyway, right?
That is also not as claimed. This would not be a problem IF Plone was available in the same format on different systems - GnuCash is, Apache is, Plone and Zope are not compatible between distributions (and besides, why are there two?). I cannot install the same software on Fedora as I do on Debian, the two don't even use the same config file locations. Get it sorted out - get the Debian maintainer talking to the Fedora package maintainer and the others. It's basic stuff - stuff that respectable packages like Apache, MySQL, GnuCash, GnuPG, KDE, Gnome etc. have sorted out long ago. When you install on a different distribution, you expect the package to iron out the differences between the distributions and give you the same interface to the same software. I know Debian, I DON'T know Fedora but I should not need to know the intricacies of Fedora vs Debian just to get a CMS portal operating! Why should I have to change distribution to match the webhost? Why should the webhost change distribution to match me? I'm perfectly happy on Debian - the webhost in this particular case is using Fedora. No other software complained or gave different results when copied between the two. This is basic stuff, Matt. If Plone insists on a single monolithic (binary) data file that cannot be patched or fixed, then it is entirely the fault of the developers if that single, unfixable, file cannot be transferred to and from EVERY implementation supported by the project, with "five nines" reliability. Note: *supported* - if it doesn't work, say so. Tell me Zope/Plone is unsupported on Fedora or Debian, that would explain a lot. Any GnuCash file is readable and writeable by any GnuCash program, subject only to the package versions being approximate. Install GnuCash 1.8.x on MacOSX, Debian, Fedora, Slackware, Gentoo, BSD, whatever. Who cares? Copy the XML file between installations and it WILL work. I installed the current versions of Zope/Plone at that time on Debian, MacOSX and on Fedora. Both worked on their own but neither could read the user data from the other. More depressing was that Debian unstable versions could not create a file readable by the Debian stable versions, or even open the Debian stable versions! Not only is Plone not backwards compatible, it isn't even self-consistent! Come on, Matt, transferring a Plone site from MacOSX to Debian should be easy! It simply didn't work, the website was completely trashed - and not just once. It discredits free software when developers hide behind false claims and don't fix problems in their own design that inhibit or prevent the free exchange of data that free software is intended to create. Plone is free software, it is not meant to remove from the user the freedom to use their data on a different implementation of Plone. Fix the bugs. Data.fs must either: be split into user-editable config files like most Unix/GNU programs, or be editable using an external utility outside Plone and Zope. Monolithic binary file formats are more akin to Microsoft than GNU!
Plone does not integrate well with other site features like an external archive, existing database scripts and external programs. You can extend it with Python but it cannot bring external non-Python content into the CMS pages.http://plone.org/documentation/howto/integrate-php-applications/
Tried it, didn't work, wasn't complete, support was patchy and uni-directional and the scripts would have needed almost total re-writes. In contrast, the enhanced Wiki takes the scripts as they are and works, all that needed changing was a few relative paths.
Okay, on Debian.
Only one system was Debian, the test system was Fedora (I'm not sure what is running on the other site - I've never needed to know). I had a second test site running Debian stable - didn't transfer correctly either. I had a Mac OSX install but that could not read ANY of the other files.
apt-get install zope2.7
Matt, we've been here before all last year - off list. I spent (wasted) six months on this flight of fancy and it does not work. Simple.
emacs /etc/apache/httpd.conf (having installed libproxy and mod_rewrite)
Why? The whole proxy thing is over-complication - what's more it doesn't transfer between sites.
Back to terminal, apachectl graceful.
Apache breaks.
Voila.
It is nowhere near that straightforward to implement on a remote server using SSH - there should be no single data file and no requirement for Apache config changes.
Personally, I found Plone was slow, cumbersome, difficult to secure, difficult to adapt and impossible to backup or transfer between sites.You may have had Debug mode on. It can be slow in Debug mode, else it's pretty nippy.
No, Matt, we've been here, we turned debug off - remember? That was done in about week 2. It was just as slow. This is not a slow server, it's modern, capable and has more than enough power - it was just that Plone via the proxy and a monolithic data file is simply a demonstration of inefficient programming.
You can do both. Furthermore, Plone is standards based, and easy to use, and doesn't reinvent the wheel.
?? OK the standards are fine, but it does reinvent the entire Apache config for no good reason.
I'm sorry you feel that way, but I wouldn't recommend anything else.
If your recommendations cannot take account of honest criticism from someone who has spent months trying to demonstrate the claims made by the software, how reliable is your advice? I did not set out to find fault in Plone, you know exactly how much work was involved in testing it and I did everything within my power to sort out the problems. The basic design is wrong - monolithic data files are a bad idea, requiring the apache proxy is a bad idea, rigid templates are a bad idea. The end result in no way lives up to your claims. I tried, I gave it everything I could and it failed. I am not averse to hard work fixing computer problems, I am not unskilled in the management of web servers, websites or most things Debian. I know my way around httpd.conf and have fixed many broken virtual host configs. With all that knowledge, experience and time, Plone did NOT meet it's own promises. I cannot help but feel that Plone is a bad example of free software because it is monolithic, incompatible with it's own versions and it simply doesn't do what is claimed. -- Neil Williams ============= http://www.dcglug.org.uk/ http://www.nosoftwarepatents.com/ http://sourceforge.net/projects/isbnsearch/ http://www.neil.williamsleesmill.me.uk/ http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
Attachment:
pgp00039.pgp
Description: PGP signature