Console architecture

[Barry van Someren <go...@gmail.com>]

>From the Wiki:

"Architecture & Technologies

...

Ideally, we'll have a configuration API available. Then we could build
one or many front ends against it. For example, we may want a
command-line tool that lets you change conflicting network ports,
using the same configuration API calls made by the web console. I
might want to fool with Laszlo without rewriting the underpinnings of
the portlet-based console.

Note that the current console does not have any separation between UI
and configuration API. The Portlet classes load a kernel and start
poking at it (setAttribute, listGBeans, etc.). They have some
"renderer" classes that they delegate some work to, but they are also
tied to both portlets and Geronimo Kernel. The JSPs are separate, for
what it's worth, using JSTL and Portlet taglibs."

What are the thoughts regarding this?
I'm thinking that a real API is not required, nor strictly desired for
this configuration functionality.
Allow me to explain.

As Geronimo grows and more people have different ideas with it (and
wish to integrate different services), the configuration API would
need to be very permissive of changes as you need to be able to slot
your GBeans into this API so that you could also write a portlet for
it.

I will not pretend to be an expert nor pretend that I know best.
But since I have taken a liking to tinkering with the console code, I
might want to help in this area.
This discussion is to see what's out there and what possibilities there are.

Personally I think that manipulating GBeans is the way to go (JMX or
our own API) as you'll undoubtably need to tie the resulting
configuration screen into the GBean.
Somebody correct me with a better idea.

In the mean time, I'll be learning more about the current architecture.

Regards,

Barry