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

[Uli Fouquet]

Hi there,

Martijn Faassen wrote:

> Thanks Philipp for watching here.
> 
> I'm not sure what the difference between the two is intended to be yet. 
> I know Uli and I discussed separating the admin UI (installation of 
> applications, server info, restart) from the introspector UI, so I 
> imagine that's what this split is about.

Sorry, the split was motivated by separating the tasks of (1) decoupling
grok.admin from grok and (2) introducing new/modified functionality into
what now is grok.admin and will be something else.

It was not motivated by splitting up something like megrok.admin,
megrok.introspector etc. Instead I planned introspector to be a
subpackage of admin, wherever this (admin) will be (and that's what I
actually did in the sandbox).

> grokadmin appears to be an extension of Grok. That's good. But it also 
> contains a copy Grok on the side. If you need to have Grok available so 
> you can make changes, please do branch Grok in 'branches' and use an 
> svn:external to that branch (or just point the trunk, if you expect your 
> changes in Grok itself to be relatively minor). Don't put copies of Grok 
> in your sandbox.

Okay, sorry for that.

> grokintrospector does appear to be a straight copy of Grok (and thus 
> should be a branch of Grok). I'm confused why this isn't a grok 
> extension as well.

As said in my other posting, it is currently modifying grok.admin,
something that will vanisch from grok.

Because I expect some heavy problems during the switch from grok.admin
to a separate grokadmin (or megrok.adminui or whatever) package, I
*started* it as a real grok.admin extension, to make sure the
functionality is available, although there should be major problems with
the outfactoring. grok.admin is therefore not the place not the place,
the introspector is supposed to be in future.

This way I can track the changes needed to implement introspector
functionality and the changes needed to factor out grok.admin from grok
better. But that does not seem to be a reasonable thing for others, so I
will put that all together tonight and see, how I can differ that
changes later on.

Anyway, I will make it all grok branches, if that is better traceable by
others.

> I think we should be focusing on simple light-weight packages that are 
> developed independently of other packages (such as Grok) as much as 
> possible.
> 
> Note that Grok extensions tend to be called 'megrok.*'. So I'd suggest 
> megrok.admin and megrok.introspector for the package names.

megrok packages, as far as I've seen, are extensions of grok
functionality. I got the impression, that they give _developers_ the
possibility to do new things. The admin UI will instead become a
standalone application (depending on grok, but not really 'extending'
it) and giving _end users_ the possibility to do new things. Therefore I
thought it would be better placed in `grokapps` or similar places than
in megrok. I might be wrong on this as well and will change also that
namespacing.

Sorry for stealing your time by my dumbness.


Kind regards,

-- 
Uli