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.

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

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