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 )

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