[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