Anne,
I was proposing first gaining a conceptual understanding of existing James
configuration, and then developing a model for how it SHOULD be configured.
Currently, JAMES is driven by XML files and Avalon interfaces. What if we
wanted to move configuration into a database or directory service? What
about dynamic reconfiguration? What if we wanted to allow configuration to
be written in XML and loaded into a dyanamic configuration store. What
about configuration via scripting? What about JMX? All of these have been
discussed before.
Assume that we want internal support for reconfiguring and deploying
components. What are the components? What are the container relationships.
What should be responsible for what?
What if all our summer projects were successful? So we'd have clustering,
fast-fail, better mailing lists, etc. How would I reconfigure fast-fail for
the SMTP server? Would I reconfigure per-cluster or per-cluster element,
and how would I effect that change? Would I have to restart the JVM? Could
I do a graceful restart such that new connections get the new configuration
and old ones live with what they have until they finish? Could an
Administrator go into JAMES administrative interface, view connections and
terminate one? Could I reconfigure a processor? Reload a matcher or
mailet? What would be the granularity for my reconfiguration / reload?
So my vision focuses on the changes to JAMES necessary to support future,
dynamic configuration and administation, rather than on the current form of
the XML files.
This would be quite a challenging project. I'd expect to see at least an
overall approach, plus implementations of at least a few things, e.g., being
able to view configuration and reconfigure some major components.
But that's just my vision. Encourage others to contribute. We are
consensus driven at the ASF.
--- Noel
-----Original Message-----
From: Anne S [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 02, 2005 11:54
To: James Developers List
Subject: Re: Google Summer Of Code - Interfaces
That would be terrific. If I understand this correctly, you are
proposing a documentation and conceptual model (less programming, more
diagramming) project, correct?
I would definitely be open to that, if you believe it to be a better
use of time. I'll draw up a revised application to reflect this.
One thing, however: Is this a replacement for just the config.xml GUI,
or both the config.xml and Remote Manager GUIs?
Thanks.
-Anne S.
On 6/2/05, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> Anne,
>
> Anything you do specifically with config.xml and user repositories today
may
> not work in future versions of JAMES, since we want to move to a more
> flexibile idea of configuration.
>
> Alternatively, you might create a model of what JAMES configuration should
> be, and then look at how to map between that model and today's
configuration
> points. Take a look at http://wiki.apache.org/james/MailingListManager as
> an example, where the entire configuration for the MLM is intended to be
> stored in a Directory Server.
>
> Personally, I feel that this might be a good way to go for JAMES in
general,
> which would support dynamic reconfiguration, easy admin, clustering, etc.
> When I look at WebSphere Application Server, they have a similar directory
> idea, except using the file system instead of a Directory Server to store
> their configuration. ezmlm also uses the file system, whereas the
> aforementioned MLM proposal takes similar ideas and moves them into a
modern
> directory server, instead.
>
> Things that could come of this:
>
> - A revisiting and better understanding of JAMES components,
> configuration and relationships.
> - A flexible structure for managing JAMES configuration
> - A mapping between that structure and today's limited
> capabilities (the XML files and user repository)
> - JMX support and documentation
> - Interfaces (UI and/or BSF) to the JMX support.
>
> Completing the first two would be a major win, and would enable the
> remainder.
>
> --- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
