[V3] Dynamic Configuration and DRAC

["Noel J. Bergman" <no...@devtech.com>]

Now that James v2.1 is delivered (Danny still needs to do some work on
Jakarta, or I need to get sufficient karma to make the changes), I'm going
back over some older e-mails ... one of which is from Kenny Smith, entitled
"Dynamic Domains."

> I would like to be able to add a domain to James without having to hard
> code it in the config.xml and without having to restart.

This should be a feature goal for James v3.  Do you know the Wiki?  :-)

> 1) Write code to replace the <servername/> entries in the config.xml with
>    JDBC calls.

We need to discuss, generically, how we want to handle dynamic
configuration.

One method, as a strawman, might be to view the current config.xml as a
bootstrap, and to have configuration handlers that can go out to other data
sources, and call methods on James to affect configuration.  So you might
have a configuration handler that would lookup server names from JNDI or
from a database, and it would call a method on James to add a new server
name.

> 2) Stop using SMTP-AUTH (the thing requiring the hard coded domains), and
> write code to dynamically allow and disallow mail relay.

> add a mailet to record the IP address and timestamp of a user
> when they make a successfully authenticated POP connection.

This ties in with Serge's comment about DRAC
(http://mail.cc.umanitoba.ca/drac/).

	--- Noel


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [V3] Dynamic Configuration and DRAC

[Kenny Smith <ke...@journalscape.com>]

Woo hoo! I'm happy we're back on a forward track. :) :) :)

> >I would like to be able to add a domain to James without having to hard
> >code it in the config.xml and without having to restart.
>
>
> This should be a feature goal for James v3.  Do you know the Wiki?  :-)


No, I've heard it mentioned on the list though. Is it a Jakarta project? 
I'll look on the site.

As for the v3 goal.. I'd like to suggest that we add to a 2.x. A lot of 
stuff has been talked about being added to James and we keep talking 
about a 3.x version it, but I'd really like to get to the "Release 
Often" paradigm. It's been talked about a lot on the list, but I think 
now that we are moving forward again we're all excited to work on big 
changes.

>
> >1) Write code to replace the  entries in the config.xml with
> >   JDBC calls.
>
>
> We need to discuss, generically, how we want to handle dynamic
> configuration.

Agreed. I like to throw my ideas out to see how they work with others. 
In my current situation, something that would make my life a lot easier 
is a set of objects that represent the standard user, alias, repository 
tables.

My desire: I want to write a web app to manage pop accounts and aliases, 
etc. What this requires is that I write my own object that fiddles with 
the user and alias tables. I'd love a James object I could instantiate, 
make changes to, and then commit, outside of an Avalon structure. I 
realize this might not be a doable thing, but I just want to put it out 
there to see what you think.

> One method, as a strawman, might be to view the current config.xml as 
> a bootstrap, and to have configuration handlers that can go out to 
> other data sources, and call methods on James to affect configuration. 
>  So you might have a configuration handler that would lookup server 
> names from JNDI or from a database, and it would call a method on 
> James to add a new server name.

I think I follow you... it's a little big for me to picture.

> >2) Stop using SMTP-AUTH (the thing requiring the hard coded domains), 
> and write code to dynamically allow and disallow mail relay.
>
> >add a mailet to record the IP address and timestamp of a user
> >when they make a successfully authenticated POP connection.
>
> This ties in with Serge's comment about DRAC
> (http://mail.cc.umanitoba.ca/drac/).

Yes, I use otto_relayd which is a system very similiar to DRAC and what 
I was basing the concept of my request on. I'd be interested in a way to 
plug functionality into the POP server (like we plug mailets into the 
transport processor), so that I could do special stuff during POP 
sessions. *shrug* :)

Kenny


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>