[Grok-dev] Re: on the name "Grok"
faassen at startifact.com
Wed Apr 30 11:41:40 EDT 2008
Philipp von Weitershausen wrote:
>> That goal hasn't been reached yet, but it's slowly moving forward
>> nonetheless. (__parent__ based acquisition, for instance, thanks to you).
> Yup, and it took three (!) years to get it stable and ready for merging.
> Call it frustration or whatever, but I don't think I'll get much into
> changing Zope 2 around anymore.
I'm not asking or expecting *you* to do it. But we still have a lot of
people interested in Zope 2.
>> Eventually I hope you can store a content object that's Zope 3 based
>> in a Zope 2 container, and then forget about the rest of Zope 2
>> (except security).
> There's also the publisher, which I suspect will likely be replaced by
> repoze.zope2 though. In either case, it's not the Zope 3 publisher.
Yes, true, we also need to branch off into the Zope 3 publisher somehow.
>>> Again, I question both the existence of such goals (API
>>> compatibility) and the usefulness. I doubt that much of the community
>>> is looking for API compatibility beyond the basic components and
>>> views. The rest is Plone-specific stuff, really, which we already
>>> agree, shouldn't be called Grok in any way.
>> Yes, you give the impression you're excluding quite a large bunch of
>> stuff, but let's make a list of what the base classes are, right now,
>> in Grok:
>> Model - little use in Zope 2 until Z3 content can be stored (which I
>> see as a future goal)
>> Container - same as for model
>> Site - should be useful in Zope 2.
>> Application - should be useful if this can be mixed in with a Zope
>> 2-based content class
> I'd say that those four heavily depend on the kind of Zope 2 app and
> framework (CMF, Archetypes, etc.). So not necessarily a goal for
> five.plone, I'd say.
You mean not necessarily a goal of five.grok?
I agree that Model and Container are future goals. 'grok.Application' is
probably also less useful. I think the 'Site' mixin would be useful though.
> > RESTProtocol
> These are done completely different in Zope 2 due to the different
> publisher setup. We don't even have those working in Five yet (meaning,
> pure HTTP views and XMLRPC views).
Yes, so they'd need Five-style compatibility layers, and they'll be harder.
>> Indexes - can be used in conjunction with five.intid
> Maybe, if somebody can be bothered to write a grokker that pokes ZCatalog.
I saw this as someone using the Zope 3 catalog in Zope 2. I think with
five.intid this is doable (though I'm not 100% whether anyone does it
>> Permission - maps to Zope 2 permission
>> Role - maps to Zope 2 role
> These are difficult ones because Zope 2 stores and registers them
> persistently, I believe. It's not impossible to do, just difficult.
Yes, so it's a compatibility layer "workalike" story again.
>> I'd say *most* of these look like something that the 'five.grok'
>> project should make work in Zope 2. The model and container case don't
>> make sense to port right away. The Indexes bit is hard to port, and I
>> expect so might be the traverser support, the REST support and XMLRPC
>> support, but that doesn't mean they wouldn't be useful to have.
> Sure. I'm just being realistic, perhaps a bit pessimistic about how much
> of this will actually be implemented. But you're right, that shouldn't
> discourage anybody from setting larger goals and trying to reach them.
Oh, sure, realistically all this will take a while.
>> I'd like to you to elaborate on the subset argument, as above.
> The list of base classes above was helpful and it indeed weakens my
> argument. That said, Grok isn't all just base classes. Like Tim said,
> it's a whole out-of-the-box experience. It's there to smoothen the Zope
> 3. five.grok just isn't the same thing.
Yes, I think this is a very good argument and it's very much acknowledged.
> It's a bridge that, just like
> Five, injects new life into an old platform, instead of being something
> on its own (which Grok very much is). It doesn't have Grok's identity,
> and calling it something with grok feels to me like it's stealing Grok's
> identity in a way.
> That said, I don't feel *that* strongly about it, at least not strongly
> enough for me to carry on arguing on the basis of what seems to be
> mostly intuition (about the identity of Grok) and past-experience (from
> Five). If y'all think five.grok is a fitting name, then so be it.
Thank you. I do agree with you on the identity issues: we should be
careful, and I also understand that "Grok" is way more than just the
base clasess (or even the code). I do think we can manage this though if
the name is "five.grok".
Perhaps the best way to manage this identity is to make "five.grok" a
sub-project of the Grok project and present it this way on our website.
We have some kind of section early on saying:
"Grok in Zope 2? There's a compatibility layer five.grok, blah blah here
you find it, blah blah be warned this is not the same as Grok proper and
only useful if you have applications in Zope 2 already, otherwise we
recommend blah blah)."
I think we can also use this as an argument that we in the Zope/Grok
community care deeply about letting older projects evolve forward. This
can be a powerful argument to people who are looking into using our
What do you think?
More information about the Grok-dev