Zope is greate, all reviews say so. Most of the reviews complain the documentation. I believe all come to known zope have experience the same difficults and all those remains can feel the power of zope. Not only the documentation is matter. Under the greate architecture, zope is inconsistance, non-intutive, and mistiness. To be fast to market is not enough, it must also easy to maintain, endure greate and fast change to make zope success. To make good use of zope, one should paid more attentation on content instead of control. Making separation of control and content as deep as possible. Write re-usable, structural components. I believe the following is very important : 1. re-introduce unified naming convention. encourage developers to change over this 2. move un-necessary codes from the zope kernel to user space: <base> <lang> ... 3. support of unicode 4. make zope content easy to co-operative with current technonlgy especially search engines. zope oodb is greate, but it prevent other apps to access the data, so it is difficult to contruct a local search facility. 5. support cvs style versioning 6. multiple output format 7. new scripting language, encourage separation of content and control, may be more xsl and xpointer style. Converting zope to Jpython have the following benefits: 1. Unicode support 2. draw other java components : for example, several xml tools being develop in Apache.org is very useful. If a complete re-write is not economic, at least DC should consider how to separate the content and control in zope, make the syntax easy to learn and use. Rgs, Kent Sin
I know this is probably a hot topic and will be much debated but have you guys at DC looked into this? Are there reasons why this is a good idea? Bad idea? It seems like a natural way to increase the performance of Zope while keeping all the power of OO and Python. J
From: "Sin Hang Kin" <iekentsin@infoez.com.mo> Date: Thu, 30 Mar 2000 06:48:47 +0800 To: <zope-dev@zope.org> Cc: "Zope Admin list" <zope@zope.org> Subject: [Zope] Zope in Jpython
Zope is greate, all reviews say so. Most of the reviews complain the documentation.
I believe all come to known zope have experience the same difficults and all those remains can feel the power of zope.
Not only the documentation is matter. Under the greate architecture, zope is inconsistance, non-intutive, and mistiness.
To be fast to market is not enough, it must also easy to maintain, endure greate and fast change to make zope success.
To make good use of zope, one should paid more attentation on content instead of control. Making separation of control and content as deep as possible. Write re-usable, structural components.
I believe the following is very important :
1. re-introduce unified naming convention. encourage developers to change over this 2. move un-necessary codes from the zope kernel to user space: <base> <lang> ... 3. support of unicode 4. make zope content easy to co-operative with current technonlgy especially search engines. zope oodb is greate, but it prevent other apps to access the data, so it is difficult to contruct a local search facility. 5. support cvs style versioning 6. multiple output format 7. new scripting language, encourage separation of content and control, may be more xsl and xpointer style.
Converting zope to Jpython have the following benefits:
1. Unicode support 2. draw other java components : for example, several xml tools being develop in Apache.org is very useful.
If a complete re-write is not economic, at least DC should consider how to separate the content and control in zope, make the syntax easy to learn and use.
Rgs,
Kent Sin
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
"J. Atwood" wrote:
I know this is probably a hot topic and will be much debated but have you guys at DC looked into this?
For a few seconds, yes.
Are there reasons why this is a good idea?
Few.
Bad idea?
Many. Java is not an open platform. Zope depends very much on the current CPython implementation. Java has 'stability' issues, depending on what vendor/platform/day of the week it is. No in-house Java expertise. Add to this the list of debatable reasons why doing anything at all in Java is a bad idea. The bottom line is probably that we don't trust Java like we trust C and Python. If Java sticks around for as long as either C or Python, then maybe I'll trust it a little, but never more than that as long as it is a closed platform.
It seems like a natural way to increase the performance of Zope while keeping all the power of OO and Python.
Increase? I think that's highly debatable. We could put just as much effort into increasing the performance of the CPython JVM or rewriting components of Zope in C and probably get a much higher performance return than depending on any one of a number of wildly different Java implementations to give us that. -Michel
J. Atwood writes:
I know this is probably a hot topic and will be much debated but have you guys at DC looked into this? Are there reasons why this is a good idea? Bad idea? It seems like a natural way to increase the performance of Zope while keeping all the power of OO and Python.
*Increase* performance by rewriting in Java? You've been reading Sun's press releases again and, worse still, actually believing them; don't make that mistake! :) I can think of any number of improvements that could be made to Zope, but a translation into another language, with no clear idea of what actual problem would be solved by the translation, isn't one of them. -- A.M. Kuchling http://starship.python.net/crew/amk/ "You mean you want to help the people who've been hurt?" "Actually, I was thinking more about me and my quality of life. But if people get helped as a byproduct I can live with it." -- Sinita and Shade in SHADE #64
Ok.. so I opened up a can of worms. Thanks to everyone for setting me straight. I do think, though, that performance and benchmarking should be an issues on the tips of DC tongues. I have been doing a lot of benchmarking (and will publish results soon) trying to figure just where the bottlenecks are (DTML, references, SQL, size, caching). The good and bad news is that there seems to be no difference in many of the different tests. I can get a MAX of 40 requests per second, and that, is that. The reason I asked about JPython and performance was because I get a lot of developers telling me that Servlets are much faster. Now, that being said I am about to set up a website with servlets and pound on it till it bleeds to see if it is true. One of the comparisons that would be nice on Zope.org would be the servlets vrs Zope. (JServ, Enhydra, etc). Thanks, J
From: "Andrew M. Kuchling" <akuchlin@mems-exchange.org> Date: Thu, 30 Mar 2000 09:57:28 -0500 (EST) To: Zope Admin list <zope@zope.org> Subject: [Zope] Re: [Zope-dev] Re: [Zope] Zope in Jpython
J. Atwood writes:
I know this is probably a hot topic and will be much debated but have you guys at DC looked into this? Are there reasons why this is a good idea? Bad idea? It seems like a natural way to increase the performance of Zope while keeping all the power of OO and Python.
*Increase* performance by rewriting in Java? You've been reading Sun's press releases again and, worse still, actually believing them; don't make that mistake! :)
I can think of any number of improvements that could be made to Zope, but a translation into another language, with no clear idea of what actual problem would be solved by the translation, isn't one of them.
-- A.M. Kuchling http://starship.python.net/crew/amk/ "You mean you want to help the people who've been hurt?" "Actually, I was thinking more about me and my quality of life. But if people get helped as a byproduct I can live with it." -- Sinita and Shade in SHADE #64
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
----- Original Message ----- From: "J. Atwood" <Jatwood@bwanazulia.com> To: "Andrew M. Kuchling" <akuchlin@mems-exchange.org>; "Zope Admin list" <zope@zope.org> Sent: Thursday, March 30, 2000 10:44 AM Subject: Re: [Zope] Re: [Zope-dev] Re: [Zope] Zope in Jpython
The reason I asked about JPython and performance was because I get a lot of developers telling me that Servlets are much faster. Now, that being said I am about to set up a website with servlets and pound on it till it bleeds to see if it is true.
One of the comparisons that would be nice on Zope.org would be the servlets vrs Zope. (JServ, Enhydra, etc).
Comparisons of this type are always quite difficult to pull off. I know that the applications I've created are rather Zope-specific. I designed them for Zope and they take advantage of Zope's features. It would be really difficult to try to do a reasonable comparison, because Zope has features the other systems don't. Sure, I could make a servlet that acts kind of like an app of mine, but how would I simulate retrieval of data from the ZODB and acquisition and the like? I'm sure that I'm paying a performance price for things like the ZODB and acquisition... but I think that price is offset by the productivity improvements that I get as a result. Kevin
"J. Atwood" wrote:
Ok.. so I opened up a can of worms.
Nah... it's on topic.
Thanks to everyone for setting me straight. I do think, though, that performance and benchmarking should be an issues on the tips of DC tongues. I have been doing a lot of benchmarking (and will publish results soon) trying to figure just where the bottlenecks are (DTML, references, SQL, size, caching). The good and bad news is that there seems to be no difference in many of the different tests. I can get a MAX of 40 requests per second, and that, is that.
The reason I asked about JPython and performance was because I get a lot of developers telling me that Servlets are much faster.
That is because there is no high level framework with servlets. There is no standard authentication framework, acquisition framework, standard object/relational model, template language, through the web managment system, object publishing over multiple protocols... servlets don't come with an HTTP, FTP, PCGI and a FastCGI server. All of this you get with Zope out of the box.
Now, that being said I am about to set up a website with servlets and pound on it till it bleeds to see if it is true.
It may very well be. With the subsequent open sourcing of ZEO however, you could scale your Zope application invisibly to a hundred machines, how far can you scale that Servlet without making any changes to it at all (or not paying money)? Requests per second is only one tiny factor of scale, and when you scale beyond a handful of machines it becomes less and less important. -Michel
All, Has anyone used Andrew Kuchling's Oedipus package (parses and displays ODP data from dmoz.org) with Zope ? In the Oedipus 0.0.7 distribution there is a .gz file with what looks like a Zope product distribution. But unpacking it in the usual place for zope products doesn't make it visible in my Zope Products folder. I am using Linux RH 6.1, Zope v 2.1.6, Oedipus v 0.07. Any known problems ? Do I need to have XMLDocument imported before Oedipus will import ? Help ! Nitin Borwankar, nitin@borwankar.com
Sin Hang Kin wrote:
Not only the documentation is matter. Under the greate architecture, zope is
I believe the following is very important :
1. re-introduce unified naming convention. encourage developers to change over this
Consistent, everywhere? This would require incredible re-writing and probably break alot. We'd rather come up with some newer, cleaner interfaces and deprecate the old ones. You're in luck, because now you can propose new interfaces and corrections for existing ones, complete with your prefered unified naming convention at the Interfaces Wiki: http://www.zope.org/Members/michel/Projects/Interfaces
2. move un-necessary codes from the zope kernel to user space: <base> <lang> ...
I'm not sure what you mean by user space. Zope is pretty well segmented, we do need to clean up the application itself a bit.
3. support of unicode
Ah, as soon as python does, we do. Also, soon there will be a Japanese Vocabulary to support Japanese searching of text, and after that we are going to try Chinese. In Zope 2.2, using these examples, you can create a Vocabulary object for the language of your preference.
4. make zope content easy to co-operative with current technonlgy especially search engines. zope oodb is greate, but it prevent other apps to access the data, so it is difficult to contruct a local search facility.
This is kind of vague, nothing in ZODB is specific to the way Zope stores its objects, currently Zope uses a FileStorage but there is nothing preventing you from creating an XMLStorage or a FileSystemStorage or a ReiserFSStorage or what have you. Doing what you want here can be done right now, it just has do _be_ done.
5. support cvs style versioning
Same as 4, all of the hooks and technology is there to support this, it just needs to be done.
6. multiple output format
Can you define this better?
7. new scripting language, encourage separation of content and control, may be more xsl and xpointer style.
Well, there is some experimental stuff going on, but probably not anything like xsl or xpointer, more like dealing with templates applied to textual content that has structure. Also some people are working on introducing some more xml based tools in Zope. Keep in mind also that all the hooks are there, you just have to come up with an implementation. There is nothing in Zope that says you can't look at the entire thing as XML or whatever, in fact, this can all hapen right now.
Converting zope to Jpython have the following benefits:
1. Unicode support
This is one of the few genuine benefits, and soon it will be supported in CPython so it's not a very pressing issue.
2. draw other java components : for example, several xml tools being develop in Apache.org is very useful.
You can still use those components with Zope; why would you want them all to be in the same language? If those components have well defined interfaces that Zope can work with why does it matter what language they are written in? I don't see this as a benefit.
If a complete re-write is not economic, at least DC should consider how to separate the content and control in zope, make the syntax easy to learn and use.
Yes, we are working on these issues right now. -Michel
3. support of unicode
Ah, as soon as python does, we do. Also, soon there will be a Japanese Vocabulary to support Japanese searching of text, and after that we are going to try Chinese. In Zope 2.2, using these examples, you can create a Vocabulary object for the language of your preference.
Just on this subject : a) You may find the Perl mandarin text-splitter at www.mandarintools.com very useful. I rewrote it in Python once but my Perl sucks so you may wish to do this yourself. Otherwise, e-mail me for copy ... it's so short I'm sure you'd rather not trust mine though. b) What algorithm do you use in your searching of text ? Is it just a simple frequency tally ? chas
participants (7)
-
Andrew M. Kuchling -
chas -
J. Atwood -
Kevin Dangoor -
Michel Pelletier -
Nitin Borwankar -
Sin Hang Kin