tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Troy Poppe <t...@usite.net>
Subject Re: request for review: server/config discussion
Date Wed, 21 Jul 1999 02:53:27 GMT
On Tue, Jul 20, 1999 at 07:44:39PM -0700, James Todd wrote:
> i see a couple of dimensions unfolding here and, while i prefer
> to keep things simple in the early stages so that we can start
> proto-typing some of the these concepts, we should still strive
> to aim high, a possible target being:
> 
> 	if the "config service" supports http as one communication
> 	protocol (lots of good reasons to do this)
> 
> 	it will need to rely on an http server (or embedded
> 	server)

Is there such a thing as an infinite loop in design? ;)
This definately could be an option, and I agree, Tomcat would
fit the bill well.  However, I think we need to generalize this
more, being careful not to err on the side of over-generalizing.
I'm seeing the configuration API as nothing more than a stub
for any number of configuration/persistance options.

I don't see why we couldn't do something similar to the JCE/JCA
from Sun.  In this architecture/implementation, you have the
ability to write your own 'providers' for encryption algorithms.
Now, this type of architecture could apply closely to configuration
IMO.

Imagine the following scenarios:

	- Configuration from LDAP or other directory service via JNDI
	- Configuration via an HTTP server
	- Configuration from a flat file
	- Configuration from a database

Then to add to the complexity of these scenarios, toss in the flavor
of XML or your choice, DTDs, XSchema, etc.  I like the idea of all
of these, but I also understand that some organizations may not want
to bring their configurations from a flat file, or LDAP for that matter.

If the API is simple, and we allow others to extend it to do whatever,
I think we're really going to build something rather powerful.

My $.01 (is it work $.02?).

- Troy

Mime
View raw message