[Gsoc] Introspector projects

Uli Fouquet uli at gnufix.de
Tue Apr 1 11:23:12 EDT 2008

Hi there,

we all might have noticed the glut of 'introspector' related projects
planned this year :-)

I'd like to clarify this topic a bit, at least for my own project
proposal, to distinguish it from others and then to avoid unnecessary
overlaps between the work of each. This might also improve general
chances to get more 'slots' from Google.

As I am not a mentor, I might haven't seen all 'introspector' related
projects yet and became aware of the fact, that also other students
could not see my own application proposal. I therefore put it on


and added a link in the zope GSOC2008 wiki page. Maybe other students
that didn't it yet, want to publish their applications as well. Or is
there already a place, where one can see the applications without being
a mentor?

Until now I counted three projects with 'introspection' related targets:

- Martin Lundwall wants to work on a "Component Registry Helper" based 
  on Lennarts call for feature requests.

  This project seems to focus on Zope2/Plone and the component 
  registry only (i.e. not on ZODB related stuff).

- Rafael Oliveira proposed a project for browsing the ZODB with a 
  graphical (wxpython-based) client.

  This project seems to focus on the ZODB only (i.e. not on component 
  registry) and an external client.

- My own proposal is focused on Grok and wants to provide both, a ZODB 
  browser as well as a component registry browser. It is also partially
  based on Lennarts call for requests.

  As a Grok-related project it also should display Grok-specific 
  runtime information like Grok directives used/available etc.

  Furthermore it wants to provide first simple possibilities to change 
  values in the ZODB/registry where appropriate.

Did I miss a relevant project proposal here?

Because a well-thought Grok-introspector should examine and display also
things, that are relevant in non-Grok-environments like plain Zope2 or
Plone, a common base library might be helpful.

Furthermore I proposed to design this library in a way, so that
gathering, presentation and eventually writing of runtime information is
separated from each other. 

Example: the interfaces implemented by a certain class should not be
fetched by code, that itself implements a certain view which is in turn
strictly bound to Five. Instead I could imagine a library that, like
``martian``, is relatively low-leveled in its dependencies. Special
entities that occur only in Plone/Grok/... environments then might be
handled by plugins or extensions to this base library.

I think such a library could be a task for Martin Lundwalls project,
although I didn't get a response from him yet. I could try to help out
with some subtopics, especially because I am a bit in it from last
years' GSOC.

If this is not an option, I indeed had to rewrite the Grok-introspector
in the described way on my own and split it into base- and extension
libraries that later-on could also be used by non-Grok packages.

If you, especially Martin, have proposals how to separate our projects
better, I would be glad to hear of it.

Kind regards,


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.zope.org/pipermail/gsoc/attachments/20080401/2d53d09e/attachment.bin

More information about the Gsoc mailing list