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

[Martijn Faassen]

Philipp von Weitershausen wrote:
[snip]
>> 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.

[snip]
>> 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).

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

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

[snip]
>> 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.

[snip]
>> 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 
technology.

What do you think?

Regards,

Martijn