On Fri, April 3, 2009 21:18, Aleksey Tsalolikhin wrote:
Hi. FYI, I have a client using Zope 2 in production. I am migrating him from Zope 2.7 on SUSE 10.1 to Zope 2.10 on CentOS 5.2.
He's not using plone. He has a custom Web app. He expects to keep using Zope 2, and to continue development of our Web application.
hi there. i think it's important for you guys to let you know that xlhost.de is also run completely on a zope backend. we use 100% zodb for all business objects. we were able to jump from release to release starting back then at 2.6 and now latest 2.10 is running since a few days. there were two products that actually broke during this time when moving to a new major zope 2 version: - localfs, as discussed which needed a few minor tweaks to keep it running. i did them myself, primarily because i wanted to keep going on immediately and i didn't want to look or even wait for a fixed version. it wasn't rocket science to make those corrections to the code, so no maintenance nightmare in sight here. - unrestricted pagetemplates, i had to come up with my own solution here, because it broke when moving to 2.8 and had some patches on board that deeply relied on 2.7 interna, as far as i remember. work needed was ~2h, so nothing to worry about either. otherwise the upgrades were always pretty smooth, i like the "big monolythic tarball release" very much, as the upgrade process is very straightforward: download, unpack, build, install. in cannot see this "maintenance nightmare" asf. that certain people on this list proclaim to exist regarding zope2. as long as all those zope3-ish stuff and it's docs (if they really exist) is so scattered across million places, all that stuff is pretty unattractive to "old school" zope users like myself, that have to keep a business running based on zope2. would i have to choose a appserver/db/whatever again for my backend, i'd go for something else, but not zope anymore. reason? well just look at zope.org, enough said. not even a basic version of a new page has made it to life yet - reasons therefor? i don't know. i've been following zope and zope-dev mls for quite some time and over time the tone spoken here has not improved, rather the opposite is true. this is quite contrary to a few other devel mls i'm on! please don't get me wrong, i don't want to piss anybody off here. i'm quite happy to have zope running, and it's running very fine indeed. i can help myself out with almost all problems nowadays, but i have people in mind that are new to zope and want to try it. and if i try to "feel" the situation these folks are in, i'd probably not choose zope for various reasons. seems like more and more things are dying in the zope world :( the only thing i can try to suggest for real improvement is: get things going. try them. don't kill good ideas by bad discussion right from the start. think positive. :) otherwise the zope community will never grow again. everybody can decide for himself it community growth is a good thing for him or not. i think some people are of the latter kind :/ just my two cents, it was time to speak up. in no way did i mean to insult anybody personally here, just in case... best regards and keep up the good work! jürgen herrmann --
XLhost.de - eXperts in Linux hosting ® <<
XLhost.de GmbH Jürgen Herrmann, Geschäftsführer Boelckestrasse 21, 93051 Regensburg, Germany Geschäftsführer: Volker Geith, Jürgen Herrmann Registriert unter: HRB9918 Umsatzsteuer-Identifikationsnummer: DE245931218 Fon: +49 (0)700 XLHOSTDE [0700 95467833] Fax: +49 (0)700 XLHOSTDE [0700 95467833] WEB: http://www.XLhost.de IRC: #XLhost@irc.quakenet.org
Thanks for this post Jürgen. You made me think of my agenda. My agenda is to promote Zope/Plone as a great way to create web applications that you also want to distribute as desktop applications. I have posted about this a long time ago but there is no reason for anyone on this list to remember, especially if this feature of zope/plone is of no interest to them. So from now on I am going include it in my sig. Also, I have been critical of the zope 3 line because I love zope 2 and it appears to me that zope 3 is killing zope 2. I'd rather not be an enemy of the zope 3 team. Grok is great but I cannot distribute grok applications to most users. However, If somebody made it possible to run django or jinga2 templates in zope 3 I would be back into Phillip's book in a flash. The reason is because I think zope is a lot more like the google app engine's back end (called big table) than a relational database is. App engine uses django templates and there is currently no way to migrate applications off app engine. Seems like an opportunity for someone who really knows zope well. Zope/Plone is still the best way to get a full stack (webserver - business layer - database) on a users desktop. It installs on mac and windows with one click. It is etter than LAMP or Adobe AIR. Please recommend plone to newbies and casual zope developers. Thanks! On Fri, Apr 3, 2009 at 4:39 PM, Jürgen Herrmann <Juergen.Herrmann@xlhost.de> wrote:
On Fri, April 3, 2009 21:18, Aleksey Tsalolikhin wrote:
Hi. FYI, I have a client using Zope 2 in production. I am migrating him from Zope 2.7 on SUSE 10.1 to Zope 2.10 on CentOS 5.2.
He's not using plone. He has a custom Web app. He expects to keep using Zope 2, and to continue development of our Web application.
hi there. i think it's important for you guys to let you know that xlhost.de is also run completely on a zope backend. we use 100% zodb for all business objects. we were able to jump from release to release starting back then at 2.6 and now latest 2.10 is running since a few days. there were two products that actually broke during this time when moving to a new major zope 2 version:
- localfs, as discussed which needed a few minor tweaks to keep it running. i did them myself, primarily because i wanted to keep going on immediately and i didn't want to look or even wait for a fixed version. it wasn't rocket science to make those corrections to the code, so no maintenance nightmare in sight here.
- unrestricted pagetemplates, i had to come up with my own solution here, because it broke when moving to 2.8 and had some patches on board that deeply relied on 2.7 interna, as far as i remember. work needed was ~2h, so nothing to worry about either.
otherwise the upgrades were always pretty smooth, i like the "big monolythic tarball release" very much, as the upgrade process is very straightforward: download, unpack, build, install. in cannot see this "maintenance nightmare" asf. that certain people on this list proclaim to exist regarding zope2.
as long as all those zope3-ish stuff and it's docs (if they really exist) is so scattered across million places, all that stuff is pretty unattractive to "old school" zope users like myself, that have to keep a business running based on zope2.
would i have to choose a appserver/db/whatever again for my backend, i'd go for something else, but not zope anymore. reason? well just look at zope.org, enough said. not even a basic version of a new page has made it to life yet - reasons therefor? i don't know. i've been following zope and zope-dev mls for quite some time and over time the tone spoken here has not improved, rather the opposite is true. this is quite contrary to a few other devel mls i'm on!
please don't get me wrong, i don't want to piss anybody off here. i'm quite happy to have zope running, and it's running very fine indeed. i can help myself out with almost all problems nowadays, but i have people in mind that are new to zope and want to try it. and if i try to "feel" the situation these folks are in, i'd probably not choose zope for various reasons. seems like more and more things are dying in the zope world :(
the only thing i can try to suggest for real improvement is: get things going. try them. don't kill good ideas by bad discussion right from the start. think positive. :)
otherwise the zope community will never grow again. everybody can decide for himself it community growth is a good thing for him or not. i think some people are of the latter kind :/
just my two cents, it was time to speak up. in no way did i mean to insult anybody personally here, just in case...
best regards and keep up the good work!
jürgen herrmann --
XLhost.de - eXperts in Linux hosting ® <<
XLhost.de GmbH Jürgen Herrmann, Geschäftsführer Boelckestrasse 21, 93051 Regensburg, Germany
Geschäftsführer: Volker Geith, Jürgen Herrmann Registriert unter: HRB9918 Umsatzsteuer-Identifikationsnummer: DE245931218
Fon: +49 (0)700 XLHOSTDE [0700 95467833] Fax: +49 (0)700 XLHOSTDE [0700 95467833]
WEB: http://www.XLhost.de IRC: #XLhost@irc.quakenet.org
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Looks like gmail won't append a sig to a draft email. Anyway here is my sig. -- Tim Nash Lead Developer http://www.sanmateowaveforms.com Zope/Plone: distribute your web applications as desktop applications. Installs on mac and windows with one click.
Tim Nash wrote at 2009-4-5 14:05 -0700:
Also, I have been critical of the zope 3 line because I love zope 2 and it appears to me that zope 3 is killing zope 2.
I share your feeling. With my current experience, the Zope 3 way to handle skins is considerably more work then the previous CMF skinning. True, you have a separate namespace for views and thus avoid name clashes in edge cases -- but is this really worth the extra effort? -- Dieter
On Fri, Apr 10, 2009 at 08:55, Dieter Maurer <dieter@handshake.de> wrote:
With my current experience, the Zope 3 way to handle skins is considerably more work then the previous CMF skinning. True, you have a separate namespace for views and thus avoid name clashes in edge cases -- but is this really worth the extra effort?
Yes, without any doubt whatsoever. And when it comes to effort, you have a point. Zope 3 in itself is too fragmented, too low level and too XML-y. Grok solves that. Zope 3 was also too big and monolithic. The eggification process solved that (and made Zope3 pointless as an application server, and it became a toolkit/framework). And some central parts of Zope 3, in particular the publisher, are too complex. Repoze and Repoze.bfg solved that. That means that for most cases, except when you need Zope 2 compatibility, The Thing That Once Was Known as Zope 3 are now finally ready. Obviously there is not much point in porting projects, but if you start a new project, the extra work of learning Grok or repoze.BFG could very well be worth the effort. I love Zope 2 as well, although I forget sometimes, since I never work with Zope 2, I work with Plone. Which I don't love (but Plone 4 looks like I will love it again). But with the Zope Toolkit I can do everything I want to do with Zope 2, with less code and less magic handwaving, and less (un)expected problems. We who know Zope 2 can develop in it easily and without problems. But it WAS a pain to get to that point. Zope 3 had a completely different set of pains. IMO, Grok has a much lesser pain level. Yes, Zope 3 did kill off a lot of interest in Zope 2, and was a contributing factor to the fact that Zope 2 doesn't attract new developers. But it wasn't the only one. It was already losing mindshare because it was too painful to use, and Python people didn't like it. People went from Zope to Python, not the other way around. With a time machine, much could have been done differently. But it's too late now. Time has ran away from Zope 2, Zope 3 never took off. It's time to take the experiences and the vast codebase, and move forward. And I guess Zope Toolkit, Grok and BFG is that way forward. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Jürgen Herrmann wrote:
- localfs, as discussed which needed a few minor tweaks to keep it running. i did them myself, primarily because i wanted to keep going on immediately and i didn't want to look or even wait for a fixed version. it wasn't rocket science to make those corrections to the code, so no maintenance nightmare in sight here.
Given that so many of you seem to be doing this, why not one of you actually pick up the patches, apply them, release a version and maintain it until you no longer need LocalFS? All this independent patching seems a little insane... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
participants (5)
-
Chris Withers -
Dieter Maurer -
Jürgen Herrmann -
Lennart Regebro -
Tim Nash