[Grok-dev] Re: Benefits of Grok -- please contribute

Martijn Faassen faassen at startifact.com
Wed May 16 17:06:33 EDT 2007


Hey,

Sebastian Ware wrote:
> Proprietary
> -J2EE
> -.NET
> -PHP

Isn't PHP open source?

[snip]

Here you list drawbacks of Grok. I'm not disagreeing with the existence 
of drawbacks or even these drawbacks. It's just something I can give 
some comments about that might mitigate some of the drawbacks, or help 
us think about how to mitigate the drawbacks in the future.

> -Zope3 lacks many features found in Zope2 (such as some of the nice 
> index types found in Zcatalog)

Actually I don't think this is true. Zope 3 has quite a few index types 
available. zc.catalog's SetIndex is much more powerful than KeywordIndex 
in Zope 2, and zc.relationship is extremely powerful for relationship 
indexing.

The problem is that all these index types are scattered around several 
packages. Grok should fix this by making them easily available.

> -No apparant commercial backing (marketing, support, accountability etc.)

There has been some talk about making Grok an official Zope Foundation 
project. We're currently trying to figure out what that would even mean, 
but if we manage to do this, that should help in this department.

[snip]
> -Poor documentation

I wrote it myself, so my ego doesn't let me call the tutorial *poor*. :)

Limited documentation, yes. There is in fact tons of documentation 
hiding out in doctest form inside of Zope 3 that we should expose, and 
we have tons of interfaces.py files around as well with API 
documentation. If a bunch of dedicated volunteers worked on a way to 
publish all this on the web we'd suddenly have Zope 3 in quite a good 
position.

For Grok, we need to push forward the tutorial and get the reference in 
a working shape.

> -No roadmap

Actually that's not entirely true - we got blueprints in launchpad:

https://blueprints.launchpad.net/grok/

Unfortunately they're hardly complete. Lots of our plans are in our heads.

What do people wish to see in a roadmap?

> -You have to restart the server when you change code

Besides Zope 2 when used with the ZMI, and probably PHP, I think all 
other competing frameworks have this requirement. Some such as Django 
and TurboGears automatically restart stuff when it detects code has 
changed. This would be a nice thing to have for Grok, though it would 
also be nice if we could get Grok to restart more quickly than it does 
now. If we can crack the whole 'change code without restart' problem 
that'd be great, but I know it's a very difficult problem to really fix. 
Philipp and Christian should be able to say more about this.

Regards,

Martijn



More information about the Grok-dev mailing list