[Gsoc] Project List

[Philipp von Weitershausen]

On 29 Mar 2007, at 11:36 , Stephan Richter wrote:
> I just checked the project list and I think having 2 Grok projects  
> in the top3
> is a bit excessive.

We have student application, willing mentors and mostly positive  
votes. What's the problem?

> I think Grok serves a part of the Zope 3 community, but
> so much as to warrant 2 projects. I think this is the new kid on  
> the block
> effect.

Maybe. Perhaps it's also the "this is what I've been waiting for a  
long time" effect.

> Further, I would be really disturbed, if Paul does not get one of  
> his proposed
> projects (I really do not care which one). Of all the candidates,  
> Paul has
> the most promise to become a long-term committer and advocat of  
> Zope 3. He is
> also extremely smart, so he can produce very well-thought-out code.

Sure. I just need to assign a mentor to the AJAX + formlib proposal,  
you or Martijn Pieters, and it'll be in the top 4.

> Martijn, I did the measurements last year already (when I applied  
> for the
> project), and I know that converting the XML strings via schemas to  
> Python
> values is about 50% of the startup time. Pickles, on the other  
> hand, are
> quickly read, so I think the overall gain would be about 50%. For  
> example, if
> Zope takes 4 seconds to start now, it would take 2 seconds after the
> improvements. I think that wildly! improves programming comfort. I  
> would have
> never applied or suggested the project if I would have not known  
> the numbers.

That's a great improvement. A similar improvement could probably be  
made if we specified configuration in Python, because strings would  
be loaded by the Python interpreter. We would get that optimization  
(and even the pickling to pyc files) for free.

> As for switching to Python actions for configuration, I think this  
> is worthy
> thinking about.

It's spoken-out goal of several Zope 3 developers, incl. Jim and some  
of the Grok team.

Having trained more than 100 people in Zope 3 now, I've also realized  
that the slug mechanism is one of the things that confuses people  
most. Setuptools' entry point mechanism (in combination with  
configuration actions in Python) would be a definite alternative. Jim  
has suggested this before, too. (Note that pretty much all other  
Python web frameworks these days use entry points, that eliminates  
our need for documenting yet another inclusion mechanism)

> However, I think this particular problem has a wide scope and
> takes a lot of work, more than what I would expect of a student  
> during a GSoC
> project.

I must disagree here. It all depends on the focus of the work. If we  
made configuration actions in Python a priority, optimizations of the  
ZCML stuff could follow easily afterwards (convert the XML to pickle  
once, on subsequent startups feed the pickle output to the actions-in- 
Python mechanism).

> Also, the method of attack has not been fully thought out, adding to
> the risk. If someone else would commit serious time to help Paul  
> here, not
> only with design but also

also what?