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

[Raphael Ritz]

Brandon Craig Rhodes wrote:
> Martijn Faassen <faassen at startifact.com> writes:
> 
>> Hi there,
>>
>> [bunch of stuff about Grok compatibility layers]
> 
> Oh, wow - the other .grok modules let you write *exactly* the same
> code as in normal Grok, and it will work in the other framework like
> it does atop Zope 3 in Grok?  I hadn't understood that!  I'd thought
> that they were ways of "grokking" whatever kind of presentation or
> view classes the other web framework had natively.
> 

Even if this is going to be considered off-topic or completely off
(I know Germans should never try to propose a name for something to
be used globally ;-) )

When I compare the current situation here with what we do in the
Python neural network community where we have an integration
project/package called PyNN http://www.neuralensemble.org/trac/PyNN/
it occurs to me that there things are done "the other way around",
meaning there you see things like

from pyNN import neuron as simulator
or
from pyNN import genesis as simulator

in order to write simulator independent code (like

   simulator.setup(timestep=0.025)

the idea being - obviously - that by changing one line of code
(the import statement)
you can run your simulation with any modeling tool for which
there is some "glue code" to the common (Python) API.
Defining this API and organizing the collection of
"glue code components" is what PyNN is about.

If the Grok-community now wants to head in a direction where
there would be several implementations of Grok based on different
technological platforms and if one wanted to adopt a similar
approach to the one outlined above one could make that explicit
by introducing yet another top-level namespace (to avoid the confusion
of the term Grok being used for so many different things) like
primordial (for lack of a better term;
http://www.askoxford.com/concise_oed/primordialsoup?view=uk)

Then we could have

import primordial.plone as grok
or
from primordial import zope2 as grok

as replacements for the native

import grok

in cases where Grok is used in Plone or Zope 2 and the
"main grok code" would just work (TM).

Not sure that makes any sense here but it just occurred to me.

Cheers,

	Raphael (getting more and more interested in Grok these days ;-)






> If you're reproducing the same API, then I take back what I said about
> Grok as a verb and Grok as a noun.  The argument becomes Grok-the-API
> versus Grok-the-particular-implementation.  In which case, I think for
> the moment I have to give Martijn's naming scheme:
> 
> +1
>