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