tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Troy Poppe <t...@usite.net>
Subject Re: config diag, etc
Date Wed, 04 Aug 1999 18:13:40 GMT
On Wed, Aug 04, 1999 at 10:38:39AM -0700, costin@dnt.ro wrote:
> Ok, I'm totaly lost. One moment someone talks about XML ( a file format),
> then about DOM ( and API for accessing XML files), LDAP( a wire protocol),
> JNDI ( a java API to access any directory service), and so on. 

Ok clarification, again.

We're constructing our own API for this configuration service, something
that could be implemented in ANY language, on any platform, etc.  

> It would be very usefull to split this discution in 3 subtopics, and
> have separate threads:
> 
> 1. What API will be used by Tomcat ( and all other Java Clients of
> Our Config Service). Since tomcat is writen in Java, I guess it's a Java
> API ( and can't be XML :-).

Its my understanding that we will not be developing an API specific to Tomcat,
but instead, as I said above, a generic API for a service.

> - DOM - it's a standard API, but for something else ( i.e. document
> model/manipulation, not configuration/management API )

This will be internal to the implementation of the API, as it deals with
how the service interpurts a set of XML data.

> - JNDI ( a Java API !) - it's a standard extension and used a lot in Java,
> and it's designed to access hierarchical information, name services and
> directories. Directories services are used by Novel, M$, Cisco, etc to
> _configure_ their products - and JNDI seems to be the Java API for that.

This is again, specific to the implementation.  If the implemenation is written
in C/C++, JNDI is out of bounds.

> - Java classes with setXXX() methods ( sort of BeanInfo) ( like in JMX -
> and similar with the way Apache configure modules ): each client will
> define few methods, and the Config Service will call them with the actual
> data. ( in Apache the module define C callbacks which are called by the
> config API when the keyword is read )
> This is the most powerfull aproach - since you can do anything in the
> callback, and the config service is clearly separated. 
> ( well, the problem in Apache is that few modules start reading and
> parsing the file by themself ) 

Again, implemenation specific.

> 3. What file format do we want to use - and if it is a requirement to have
> a "real" file or we want to support directory services ( not by exporting
> it to a file, and then parsing again the file ) ( and loosing all the
> security, access control, replication, events of a real directory service) 
> For file format - XML seems to be the choice. 

We've decided that XML is the file format that makes the most sense for us.
It's not a decision anymore from my understanding.  As for security and
access control, this should be implemented by the service's API, and possibly
managed by the data store (LDAP, DMS, unix filesystem, etc).

> 4. What data structure/model we want to use. That seems to be clear in
> James document, if everyone agree we can clear this item.

What exactly are you saying here? I don't quite understand what you mean
by data structure/model.

- Troy

Mime
View raw message