[Grok-dev] Re: SVN: Sandbox/ulif/grokintrospector/ Create a sandbox for Grok-related introspector stuff.

Martijn Faassen faassen at startifact.com
Sat Jun 21 08:10:03 EDT 2008


Philipp von Weitershausen wrote:
[snip]
> I'm not too keen on introducing yet another namespace. We already have 
> the top-level package 'grok', and the namespace packages 'megrok' and 
> 'grokcore'.
> 
> While there might be a superficial difference between the admin 
> interface and, say, RDB integration, it's hard to draw the line where 
> exactly the "coreness" of a package ends and begins. For instance, when 
> deploying a Grok app, I might not even need or want the admin interface 
> installed. After all, it's yet another application written in Grok 
> that's installed next to my own application. Same goes for the CRUD 
> interface.

This is where the distinction between megrok and grokui lies. If you use 
a megrok extension to build your application, you really need to depend 
on it. If you use a grokui to help you in development, it's quite likely 
you only need this to help develop your application, or to manage your 
application in a production setting, but your actual code does *not* 
rely on this stuff.

> I personally think it's absolutely fine to call these things
> 
>   megrok.admin
>   megrok.autocrud
>   megrok.introspector
> 
> as they're actual extensions working *on top* of the original Grok 
> framework. Whether or not they're enabled in a default grokproject 
> buildout is another question.

I suggested they be called megrok.* too earlier in the discussion, but I 
did change my mind because I did see a clear distinction.

> Or to rephrase, I'd rather broaden the scope of the 'megrok' namespace 
> (it's just a namespace, after all) rather than introduce yet another 
> namespace.

Just as a note, for now the existing admin UI and introspector will 
remain together in a package. We aim to detach this later, but it's more 
efficient not to do this for the time being.

I think the namespaces can be distinguished quite clearly, though:

* megrok - extensions to grok offering new developer-level functionality

* grokcore - bits that Grok is built on

* grokui - user interfaces for Grok that help with development and 
management, but that typically doesn't offer infrastructure to build 
applications on (except perhaps other grokui apps). Eventually we'll 
allow people to optionally install these, i.e. deploy without grokui, or 
with a different grokui for application management.

I think the distinction between megrok and grokcore is actually going to 
be less clear than between grokui and megrok, as it's quite likely we'll 
have megrok packages become core grok at some point in the future.

Regards,

Martijn



More information about the Grok-dev mailing list