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
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.
I'm not sure it's debatable at all. JPython is a very cool integration of Java and Python, but I think it's clearly understood to be much slower than classic Python. Porting Zope to JPython is a natural way to get a much slower Zope. As a bonus, "JZope" would also be less portable, less open, and less stable. When applied to the kinds of things it was designed to do, JPython is Deeply Neato. However, porting Zope to JPython would be one of those endeavors where the "bang for the buck" ratio which is a negative number. :-) Eric W. Sink, Software Craftsman SourceGear Corporation eric@sourcegear.com
[J. Atwood, on Wed, 29 Mar 2000] :: 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. Last I heard, JPython runs at roughly 50% the speed of CPython, so I don't see how such a switch could result in a performance increase. Since Jim Fulton has written key Zope extensions in C, I'd suspect a JPython Zope would be correspondingly more than 50% slower. JPython is cool as a scripting language for Java, but wasn't, I believe, ever intended as a standalone programming language for large development projects.
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
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
I have a kindof related point about search engines... Zope doesn't like objects which have extensions. For example: index.html, so instead index_html is used. However, search engines don't like pages which DON'T have extensions. They use extensions to work out the content type of the file which saves them having to do a HEADER get to find it. A few of the major search engines simply ignore files without an extension assuming them to be scripts or downloads. It would be nice if Zope had better support for objects ending in .html, for example, instead of having to use the convoluted "_['index.html']" and others... perhaps even change the default from index_html to index.html and maybe even add a default extension of .html to DTML documents when they're served up...
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.
Are you talking about CVS style versioning for objects in the ZODB? If so then that would be very, very cool :-) Most people understand versioning to be CVS-ish versioning, and the current version objects, although very cool, don't really do this. my $0.04 Chris
participants (6)
-
Chris Withers -
Eric W. Sink -
J. Atwood -
Michel Pelletier -
Patrick Phalen -
Sin Hang Kin