Some Thoughts

Good post.  I agree wholeheartedly with parts, and disagree with others 
(language issues).

 >Limiting risks: Steve posted some helpful hints on how to develop in a
 >compatible way some days ago. Maybe we could build on that. The basic
 >concept was that you should:

Please post URL.

 >If programmers feel that Zope 3 will save them more time than Zope 2
 >does, they will switch.

Sounds like a compelling incentive.

 >What's my bottom line: Concentrating on actual migration of OLD Zope 2
 >code will not help Zope 3 development, but block it. Concentrating on
 >making it easy to develop in a Zope 3 style NOW (forward compatibility
 >like with Apple's OS 9 => X strategy) will help speeding up Zope 3
 >development and not waste resources.

Nice.  If there were a strong Zope3 forward compatibility strategy, I 
think that would be great.  As a (re^3)starter at Zope, I'd love to 
develop Zope3 style and avoid Zope2'isms if at all possible.  Is there 
a such a strategy guide, Z3 compatibility box?  That would be a godsend 
for new adopters.

 >I think that there is no big need for porting stuff from Zope 2 to Zope
 >3 in general.

I disagree but am not sure you meant that literally...

 >If something works fine on Zope 2, don't touch it. As I
 >have pointed out on the Zoep3-dev list some days ago, Zope 3 (non-x)
 >should probably be shipped with a Zope 2 (optional) engine that
 >integrates with the ZODB and ZServer and is accessible from a unified
 >ZMI, but other than that is not interoperable with the rest of the
 >system. That should be enough for most "legacy" code.

If that worked, that would be great.  The backward compatibility box 
which runs Z2 code without modification.  Nice.  Is that possible, in 
the works?  I bet people would find ways to get the two Zopes to work 
together (rpc networking at worst).  That could provide a bridge in Z3 
from Z2.

-=-

Java port clarifications:

 >With regard to Java: I personally have NO interest in a Java port.

You would not need to; you just need to want a faster zope.

Same zope, just a magnitude faster since it runs native on jvm, not 
through CPython interpreter.  You still program in python (running on 
top of jvm).  Zope would still be implemented in Python (running as 
jython3000 for speed benefits on jvm).  Speed code would be converted 
from C to Java, but as few care about the C code, few would need to 
care about the Java code.

You would mostly see speedup, and that's good, no?

 >I'd like to see parts of Zope ported to native C/C++ for speed, but I 
don't
 >need yet another language involved.

<Cough, cough>  C/C++ is other languages.  Python dovetails virtually 
perfectly with the jvm object model.  C++, not so.  Old dogs don't 
learn new tricks.  Plus, if you're doing it for speed, C++ is no faster 
than C (usually a bit slower, potentially a lot slower/bloated if 
carelessly coded).  I don't think C++ buys what you think it does.  
CPython already is C++ fast (slightly faster probably, and less 
bloated).  CPython code can't get any faster without coding directly in 
C --- which means you're not coding in python.  Doh.
	IOW, C/C++ does not speed up python code.  It interprets it for 
relatively slow execution (typical for all interpreted languages).  A 
(hypothetical) jython3000 implementation would offer something new: 
speed up of pure python code!  C/C++python can't do that.  jython3000 
would speed up python code buy compiling it and running it on the JVM.  
All of a sudden the code would be running at JVM speed which is 
(debates aside) nearly C/C++ speed for typical code (though cases can 
be made for code running faster-than-C in some cases).  The incentive 
would then become to code in pure python, and purge the C code 
completely.  For top speed, java could be used (replacing the C code) 
but the speedup would not necessarily be that great, since the 
jython3000 code would already be running at run-time compiled speed.

That's how you get rid of or minimize "yet another language" and 
approach a pure python Zope.

Furthermore, jython/java/jvm is much more aligned with the direction 
zope/python are headed language wise.  They're aggressively 
object-oriented, dynamic object model (jvm is dynamic even if java is 
strictly typed), and increasingly performance oriented.  Java adopts 
XML standards widely. The object models from python and jvm(java) 
dovetail virtually perfectly.  That's one of the beauties of jython.

Zope could cherrypick from java past(legacy)/current/future 
technologies (but you could ignore all those).  Many would work as 
freebies.  Universities and students would be much more likely to adopt 
Zope for class or research projects since it would be much more 
mainstream and "standard".  Enterprises could adopt and support zope 
with their generous budgets without taking unsavory (to them) risks.  
Zope would gain a higher profile from its participation in the java 
community.  Zope would gain mindshare in mainstream computing for any 
contributions it makes to Java.

 >I think that Zope has absolutely no chance as a new player in the Java 
world.

See above.  As I read your assertion, if Zope has no chance in a java 
world, then it has no chance today.  That's simply not the case, or we 
wouldn't be here.  If Zope has merit, then it should not just survive 
but thrive in java world.  If nothing else, a faster Zope is a better 
zope.  So ignoring all else java, and just using the JVM to get a 
magnitude speedup would be a win.  All other benefits (see above) would 
be freebies.

 >Our strategy always has been
 >to either catch people before they go Java or after they have been
 >disappointed by Java.

Weak strategy, and I doubt that's the strategy.  Zope has no java 
strategy (except perhaps a misguided Java as enemy notion).
Strategy for zope in my opinion is 'build a better mousetrap'.

 >Yes, that means that we are not completely buzzword-compatible.

That's a straw man assertion and irrelevant to the real merits of Java. 
  Speed from jython3000 is the carrot. Compatibility with huge libraries 
and technology is a win (along with other stuff mentioned above).

 >And yes that means that Zope will remain in a niche. But it's a 
comfortable niche, and buzzwords are just
 >fads that go away. Good software survives.
 >
 >ACS from ArsDigita was a perfect example of "GO JAVA => GO BANKRUPT"*.

Cheap shots, but I'd like the URL to the ACS debacle.  Sounds like a 
fun read given your citation.  Please post URL.

-=-

In sum, I think we strongly agree on the forward compatibility and 
backward compatibility issues, but you know much more zope than I do.  
For the language stuff, I'm less inclined to defer.  JVM/Zope buys:
	jython3000 (instead of slower CPython),
	magnitude speedup (see jython3000),
	java tech'y compatibility, and
	larger community sharing, development, and profile for Zope.
There are probably other significant advantages, but those should be 
enough (modulo development of jython3000).

-=-

Good post even if we have different world views on language strategies.

Thanks,

= Joe =