RE: [Zope] Re: Zope XML Roadmap
Joe wrote:
I have just started using Zope as well and am still pleasantly surprised (still working on my first useful page).
Zope on JPython is so compelling to me that I feel like that's the project for me. As I come up to speed on Java and Python, I'd like to take a crack at getting Zope onto JPython.
I'll speak to another angle of the JPython work: mindshare. Hadar Pedhazur (our board chairman and principal at our VC fund) and I recently went on an analyst tour (META, Giga, Gartner, et al.) The subject of Java servlets as the definition of application servers came up over 50% of the time. Our position currently is pretty clear: servre-side Java is a bandwagon, but a pretty murky bandwagon. Joining all the others in that market doesn't seem like an "obvious" thing to me. Java still has a lot going against it (Microsoft, poor portability, speed) and so we're doing pretty well where we are now. Case in point: $ telnet www.javasoft.com 80 Trying 204.160.241.83... Connected to www.javasoft.com. Escape character is '^]'. GET / HTTP/1.0 HTTP/1.1 200 OK Date: Thu, 22 Jul 1999 10:30:36 GMT Server: Apache/1.2.5 Now, Java has a web server. Why is the company that creates Java running a web server written in C? Isn't Java the world's best server side technology? With that said, we certainly don't want our consulting services to be artificially confined to a subsegment of the market -- that is, eliminating the perhaps large number of customers that have bought into the servlet/bean vision. Zope running in JPython is something we've always held out as being an escape hatch. Thus, we'd like to see some work on it. How might this happen? One of two ways seemed logical. Either the community would do it (with our support and endorsement) or a paying customer would require it. The jury's in now and thanks to you and Michael, it appears the first has happened.
I do have a question for the Digicool folks though, especially since this would seem to be a long-term project given all the C code and the comments on the size of
Hmmm, do you feel like there is an onerous amount of C code without Python equivalents?
the project. If a project like this were occurring, would DigiCool be happy to roll in the changes so
Certainly, but I we'd also like to make sure about the goals of such an endeavor. Are the goals speed, portability, integration (e.g. with servlets or as a bean), etc.? Thus, while I'm not telling you to stop leaping, I'm also asking that you do some looking. :^)
that they didn't get lost? I can imagine being open to such a project, but I feel like if there isn't a serious commitment, JPython support
This is a good point. We don't regard our position as publishers of Zope in a cavalier way. We realize that the things we say and do impact what others do, and if we make a sudden change in course, it can disrupt (or worse, waste) people's efforts.
might eventually just be wasted. (On the other hand, that seems unlikely given the increasingly compelling nature of Java both on the server and as a state of the art VM in speed and reliability.) I don't really understand the nature of servlets with respect to Zope, but I can't imagine having the choice between them would be too bad.
Yep, a bit of research is in order. How hard is writing a JPython-based servlet?
Aside from the porting effort I realize that there are speed issues, but for some of us portability and the simple extensibility offered by the JPython /Java combination outweigh speed considerations.
Ahh, speed. :-)
This issue is actually (if I'm reading the tea leaves properly) a driver for moving Zope to JPython. According to a presentation at JavaOne by the originator of JPython, JPython is currently on par (or thereabouts, I don't exactly remember) with Python, and the prospects for increased speed above (C)Python are on the horizon. I don't have PowerPoint, so I can't extract the details right now, but the following link has PowerPoint slides for the JavaOne presentation if anyone is interested in peeking:
http://www.jpython.org/jpython-talk-1.ppt
One of the key points to me was that the Java VM technology has advanced so far so fast that it's outstripping previous VMs dramatically. I don't remember if the speedups already included the HotSpot 1.0 JVM, but the HotSpot 2.0 JVM is supposed to be another 30+% faster, so I believe that'll make JPython that much faster than (C)Python.
I was at SPAM Houston for Jim Hugunin's first unveiling of those numbers. He confessed that they were (a) quite speculative, being based on the speculative pystone test, (b) on the horizon, meaning not here yet, and (c) all done on MS' VM. It was something like a five-fold drop when going back to the standard JDK. Perhaps HotSpot will address it, but when will it be available on Linux? On FreeBSD? On Mac OS X Server? On Digital Unix or SGI? Point is, these are nice goals and hopes, and there is some evidence on the table already, but it's still to early to predict what will actually happen and what will be the unintended side-effects.
Anyway, I think the wonderful dovetailing of Java and JPython would make Zope even more incredible than it already is and that's what I'm hoping for (since those are my three platforms of choice: Java, Zope, (J)Python).
Having a CPython and JPython/Servlet version of Zope -- boy, that would certainly make Zope pretty unique! --Oayk
At 6:55 AM -0400 7/22/99, Paul Everitt wrote:
I'll speak to another angle of the JPython work: mindshare.
...many valid comments snipped...
With that said, we certainly don't want our consulting services to be artificially confined to a subsegment of the market -- that is, eliminating the perhaps large number of customers that have bought into the servlet/bean vision. Zope running in JPython is something we've always held out as being an escape hatch. Thus, we'd like to see some work on it.
How might this happen? One of two ways seemed logical. Either the community would do it (with our support and endorsement) or a paying customer would require it. The jury's in now and thanks to you and Michael, it appears the first has happened.
I'm happy to take a look around Zope and outline how much work would be involved for the various pieces. Extra sets of eyes would be most welcome.
Certainly, but I we'd also like to make sure about the goals of such an endeavor. Are the goals speed, portability, integration (e.g. with servlets or as a bean), etc.? Thus, while I'm not telling you to stop leaping, I'm also asking that you do some looking. :^)
Not to speak for anyone else, but my goals are integration and portability, integration both with existing Java packages and also with personal devices (running Personal Java and JINI) - so I probably have a different agenda than most people here who are working on enterprise level back-ends. There is also the additional factor that life is short and I'm trying to be careful about managing my ignorance. The more things I can safely not know the more time I have to do things with what I know. If I know Python, Java and XML then I can safely avoid C , Perl etc. (since programming is a means to an end for me), and I absolutely need Java for the other projects I'm working on. The main reason I came to Zope is that I've been using Frontier a bit and didn't want to have to learn UserTalk to do small Web apps when it seemed like there out to be something available in languages I know already.
Yep, a bit of research is in order. How hard is writing a JPython-based servlet?
I haven't done it, but 'the documentation says' write the Python class and compile it to Java bytecode using jpythonc.
Point is, these are nice goals and hopes, and there is some evidence on the table already, but it's still to early to predict what will actually happen and what will be the unintended side-effects.
I'm off to collect a bit more evidence.....
Having a CPython and JPython/Servlet version of Zope -- boy, that would certainly make Zope pretty unique!
Agreed !! Cheers, Michael p.s. I won't be doing email next week, just so no thinks I'm ignoring them :) ************************************************ Michael Rose Center for Tele-Information, Technical University of Denmark mailto:rose@tele.dtu.dk http://www.cti.dtu.dk/personal/rose Multimedia in the Home - http://mmhome.cit.dk 'and what is the use of a computer' thought Alice 'without pictures or conversation' with apologies to Lewis Carroll *************************************************
Paul, I'm glad JPython based Zope is worth at least researching. I definitely need to do much "research" since Zope is my introduction to the web medium. Paul Everitt wrote:
Our position currently is pretty clear: servre-side Java is a bandwagon, but a pretty murky bandwagon. Joining all the others in that market doesn't seem like an "obvious" thing to me. Java still has a lot going against it (Microsoft, poor portability, speed) and so we're doing pretty well where we are now.
Zope is doing great, no doubt, but you guys don't seem to rest on your laurels either, so I'll chime in with a slightly different perspective on servlets! I think servlets have (to everyone's surprise) turned out to be the initial, most compelling use for Java. Everyone expected the platform independence to be the initial value-add of Java, but client-side Java was painful due to (as you point out) portability issues... mainly irreconcilable (for Java1) GUI differences. While Java2 addresses the GUI issues with new architecture, that whole issue was knottier than anyone imagined (architecturally). The great thing about servlets is that they only need to run on one machine which is controlled by the servlet provider. Zero portability problems. Zero performance issues (since you can install HotSpot which is reasonably fast, getting faster). Apparently, servlets are incredibly rock solid for servlet applications. While certain aspects of Java (e.g., client-side computing) are still currently murky, I believe what you were hearing about servlets was that they're already here. I suspect dovetailing with servlet support would be a definitively good thing, enabling people to grab existing (servlet) stuff and plug it into the awesome Zope framework hassle-free (plus Python servlets as desired :-) Also, supporting servlets naturally would eliminate any confusion that Zope is competing with Java as a platform. Java is so big and moving so fast, that many would dismiss something "new" which isn't riding the Java train (or isn't MS, I guess). Zope is doing great, but the confusion is still there. (I just proved to myself yesterday that I could still run JavaScript using Zope. Technically, a no-brainer, but I wanted to make sure I hadn't lost compatibility/options even if I don't necessarily need them now. :-) Java compatibility (servlets, applications, etc.) is a much bigger check-box item for a lot of people.
Server: Apache/1.2.5
Flux ;-). Seriously, if it ain't broke, don't fix it. I don't think everything needs to run Java, just where convenient and compelling.
Hmmm, do you feel like there is an onerous amount of C code without Python equivalents?
I don't know, just significant amounts of code. I'm going on impressions from reading the zope groups for the last 3+ months. I remember a thread that suggested JPython support was not immediately trivial. Since installing zope, I notice a significant number of C files. IOW, I need to do my "research", but I have a lot to learn about Zope before knowing well what to research.
Certainly, but I we'd also like to make sure about the goals of such an endeavor. Are the goals speed, portability, integration (e.g. with servlets or as a bean), etc.? Thus, while I'm not telling you to stop leaping, I'm also asking that you do some looking. :^)
Great. Goal for me would be seamless integration of object models with Java applications (servlets, beans, applets, etc.) to take advantage of Java libraries/Zope power. Leveraging 2 great technologies (Zope and Java) that go well together. Speed and hassle-free portability would be an ulterior motive to take advantage of the Java VMs.
I was at SPAM Houston for Jim Hugunin's first unveiling of those numbers. He confessed that they were (a) quite speculative, being based on the speculative pystone test, (b) on the horizon, meaning not here yet, and (c) all done on MS' VM. It was something like a five-fold drop when going back to the standard JDK.
Hmm, when was this unveiling? The MS VM was the fastest for some time. IBM's JDK1.1.8 VM and Sun's 1.2.x HotSpot VM are significantly faster than it now. I'd be surprised if there were a drop now at all. I would expect a speed up with either the latest IBM or the Sun.
Perhaps HotSpot will address it, but when will it be available on Linux? On FreeBSD? On Mac OS X Server? On Digital Unix or SGI?
Good points. I believe IBM has just released their JDK1.1.8 VM for Linux. That may be a good solution for Linux (albeit not Java 2 yet). Sun seems to be dragging a bit with support for Linux though which is admittedly annoying given the desirability of the JDK 1.2 support and speed of the Sun HotSpot VM. Apple seems to have no clue. They can't seem even to announce JDK1.2 support even for Mac OS X (which is largely UNIX). I don't know what they're thinking. They do have a solid (reportedly) 1.1.7+ VM now though. So the basic Java is there. FreeBSD, Digital Unix, and SGI, I don't know which probably means they have nothing so far. Your point is a good one. Clearly, there needs to be a performance solution where serious Java VM's are not available
Having a CPython and JPython/Servlet version of Zope -- boy, that would certainly make Zope pretty unique!
:-) Being able to choose between Python or Java, using an insanely great (sorry, watched the Steve Jobs keynote last night :-) application server. Yowza. I know I have to use Java, and it would be so nice to unite everything (applets, server, scripting) into one incredible whole. Cheers, = Joe = P.s., plus, Plus, I just think Java people would love Zope, but the lack of servlet support and all the features Zope has just seem to put it into competition with Java which can be confusing. Building on Java just seems so strong to me.
participants (3)
-
Joe Grace -
Michael Rose -
Paul Everitt