[Grok-dev] Re: on the name "Grok"

[Philipp von Weitershausen]

Martijn Faassen wrote:
> Philipp von Weitershausen wrote:
>> Martijn Faassen wrote:
>>> Hi there,
>>>
>>> Philipp von Weitershausen wrote:
> [snip]
>>>> I'm against calling it five.grok, to be honest.
>>>
>>> Why? It aims to provide the same API as Grok, after all.
>>
>> Does it? I haven't read its README yet, so I don't know what the 
>> intentions of the authors are. Even if those were the goals, I don't 
>> see the point of replicating Grok in Zope 2.
>>
>> Five in Zope 3 doesn't reimplement all of Zope 3 either. It just 
>> provides the most important and commonly used components. Perhaps I'm 
>> missing something, but why does five.grok need to do more than Five 
>> already does (not counting conventions over configuration, etc.)?
> 
> I always saw as the ultimate goal of the Five project the ability to run 
> Zope 3 code unchanged in Zope 2.

So did I, in the beginning. I must admit that that goal has changed for 
me, having appreciated the tremendous work that this entails (see next 
paragraph).

> 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.

> 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.

>> 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.

> Adapter
> GlobalUtility
> LocalUtility
> MultiAdapter

Yup, they're in grokcore.component.

> Annotation
> View
 > JSON

Sure.

> XMLRPC
> REST
 > 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).

> template language pluggability
> resource support ('static')
> Traverser, 'traverse' method
> Form
> AddForm
> EditForm
> DisplayForm

Yup.

> Indexes - can be used in conjunction with five.intid

Maybe, if somebody can be bothered to write a grokker that pokes ZCatalog.

> 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.

> grok.require - view level security
> IGrokLayer
> Skin
> ViewletManager
> Viewlet

Sure.

> 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.

> [snip]
>> I think the mental work is minimal. Nobody objected when Five (due to 
>> a technicality) had to introduce a BrowserView base class. 
> 
> True, though base classes don't play a fundamental role in Zope 3 
> programming.
> 
>> five.grok is in a way a special animal because it brings over some 
>> commonly used components to Zope 2. I still don't think that bringing 
>> over all of Grok is an important or even sensible goal. Therefore, 
>> five.grok will always be just a subset. And to be honest, probably a 
>> small subset (I suspect the future plone.grok will most likely be the 
>> rising star of Grok technology on Zope 2). But, who am I to predict 
>> the future :). Point is, it's not Grok and thus shouldn't trick the 
>> developer into thinking everything from Grok is available.
> 
> 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. 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.