Hello Zope developers and Zope community! I am applying with "Zope 3 on Jython improvements" to Google Summer of Code. It would be really a great help to receive some feedback on this undertaking from the community and also developers of Zope! Please have a look at the following thread on the Zope GSoC malinglist: http://mail.zope.org/pipermail/gsoc/2008-March/000136.html Thanks in advance! Kind regards, Georgy Berdyshv -- Georgy Berdyshev GPG key: 830F68C5 Fingerprint: 0379 ED5A BEE5 65A8 7BD5 31E7 F5B4 1EC7 830F 68C5
On Mar 27, 2008, at 11:51 PM, Georgy Berdyshev wrote:
Hello Zope developers and Zope community!
I am applying with "Zope 3 on Jython improvements" to Google Summer of Code.
Yay!
It would be really a great help to receive some feedback on this undertaking from the community and also developers of Zope!
Then this is a good place to post. :) Although I suggest limiting the discussion to zope-dev.
Please have a look at the following thread on the Zope GSoC malinglist: http://mail.zope.org/pipermail/gsoc/2008-March/000136.html
There aren't many details there, so it's hard to comment. Some high-level comments: - I suggest making porting C speed-ups a very low (non-existent) priority. - I expect security proxies to be one of the greatest challenges. Maybe you can make them a low-priority by focussing initially on Zope 3 applications that don't use them, like grok. - I'd be inclined to take a bottom-up approach. So, rather than trying to get the Zope 3 "application" (a.k.a. Zope-management interface, a.k.a Rotterdam skin, a.k.a zope.app.zcmlfiles) working, focus instead on zope.interface, zope.component, and zope.publisher. (Notice I didn't mention ZODB. :) Are there wsgi servers for jython? Jim -- Jim Fulton Zope Corporation
Hey, Thanks for the feedback, Jim! On Fri, Mar 28, 2008 at 3:06 PM, Jim Fulton <jim@zope.com> wrote: [snip]
Some high-level comments:
- I suggest making porting C speed-ups a very low (non-existent) priority.
- I expect security proxies to be one of the greatest challenges. Maybe you can make them a low-priority by focussing initially on Zope 3 applications that don't use them, like grok.
+1 - I already mentioned this option as well. Note that existing Zope 3 applications can at least be made to run if you just let the proxying code do nothing and return the object itself, I imagine. They'll run insecurity, but they should run.
- I'd be inclined to take a bottom-up approach. So, rather than trying to get the Zope 3 "application" (a.k.a. Zope-management interface, a.k.a Rotterdam skin, a.k.a zope.app.zcmlfiles) working, focus instead on zope.interface, zope.component, and zope.publisher. (Notice I didn't mention ZODB. :)
Are there wsgi servers for jython?
I think the Jython people already mentioned one, if I recall correctly. I agree the focus should be on the lower-level packages. Note that zope.interface was already ported at least some distance by the twisted people at Pycon. I could therefore *imagine* focusing on some speedup work by rewriting bits of code to Java, but I agree with you that the primary, initial goal should be to get things to work, and that performance work should be secondary. So perhaps this can be in an 'optional-if-there-is-time-left' section, and going in with the assumption that time will not be left. Georgy, I suggest you go through my earlier comments again, and also include Jim's comments (which are in agreement on most topics) and work those into your proposal. Regards, Martijn P.S. Note to interested by-standards, we're planning that Georgy is going to be mentored primarily by the Jython people and as part of the Jython summer of code project, not the Zope one. We are looking for a good backup mentor who can assist on Zope-specific matters, though.
On Mar 28, 2008, at 11:05 AM, Martijn Faassen wrote: ...
+1 - I already mentioned this option as well. Note that existing Zope 3 applications can at least be made to run if you just let the proxying code do nothing and return the object itself, I imagine. They'll run insecurity, but they should run.
I'd rather not have something like this checked in anywhere. I'd rather make it easier and more explicit to control whether proxies are used.
Note that zope.interface was already ported at least some distance by the twisted people at Pycon.
Interesting. Did anything get checked in to the z.o repo?
I could therefore *imagine* focusing on some speedup work by rewriting bits of code to Java, but I agree with you that the primary, initial goal should be to get things to work, and that performance work should be secondary. So perhaps this can be in an 'optional-if-there-is-time-left' section, and going in with the assumption that time will not be left.
In particular, I'd prefer to see more of the stack get ported over speedups. Jim -- Jim Fulton Zope Corporation
Hey, On Fri, Mar 28, 2008 at 4:12 PM, Jim Fulton <jim@zope.com> wrote:
On Mar 28, 2008, at 11:05 AM, Martijn Faassen wrote: ...
+1 - I already mentioned this option as well. Note that existing Zope 3 applications can at least be made to run if you just let the proxying code do nothing and return the object itself, I imagine. They'll run insecurity, but they should run.
I'd rather not have something like this checked in anywhere. I'd rather make it easier and more explicit to control whether proxies are used.
Sure, agreed that would be better.
Note that zope.interface was already ported at least some distance by the twisted people at Pycon.
Interesting. Did anything get checked in to the z.o repo?
This I don't know about. Georgy should ask the Jython people, who seem to know more. :)
I could therefore *imagine* focusing on some speedup work by rewriting bits of code to Java, but I agree with you that the primary, initial goal should be to get things to work, and that performance work should be secondary. So perhaps this can be in an 'optional-if-there-is-time-left' section, and going in with the assumption that time will not be left.
In particular, I'd prefer to see more of the stack get ported over speedups.
Yes, I think that's a good goal for the project for the forseeable (this summer) future. I don't know how hard it is to port most of the Python stack, but we will be finding out. Georgy, a report on the things you run into while porting this stuff over would also be *very* useful, so I suggest you make the production of such a report part of your plan. Of course also needed is a list of the packages you ported over, and perhaps the packages you didn't manage to because of particular issues. Regards, Martijn
Hi Jim, Friday, March 28, 2008, 4:12:56 PM, you wrote: JF> Interesting. Did anything get checked in to the z.o repo? Looks like no commits. There are two bug reports in launchpad: https://bugs.launchpad.net/~njriley+launchpad-net Nicholas Riley is the one who made that work (according to the jython-dev list) -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: The crash of the whole solar and stellar systems could only kill you once. - Thomas Carlyle
Hello, thanks for the replies! The port of the C speed-ups is a really interesting thing, but could be done if there is time left, as there are possibilities to run those zope components without using the C speed-ups. I have already heard that the Zope security proxies are a big challange and that there are ways, to concentrate for example on grok, which does not use it. The bottom-up approach is a good thing, because Zope has a huge amount of components. Some of the I would be interested in are zope.inerface (ported at PyCon), zope.component, zope.publisher and some of the xml and data structure parsing bits inside of Zope.
Are there wsgi servers for jython? There is a a WSGI server for jython: modjy http://www.xhaus.com/modjy/
As Martjin mentioned, I will also be working on a report while working on Summer of Code, to include the missing bits or parts that could not be ported to Jython, giving a status update to Jython and Zope about the missing bits. Regards, Georgy
participants (4)
-
Adam GROSZER -
Georgy Berdyshev -
Jim Fulton -
Martijn Faassen