tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: config diag, etc
Date Wed, 04 Aug 1999 18:53:50 GMT
> 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.  

Ok, but besides the fact that it will work in ANY language, on ANY
platform and support ALL existing protocols, I haven't heard anything
about the API itself. 

Will the client pool the config information using a get method or will the
config service push the data ( or both )?

Will it support notification or will poll for changes ( and how can you
detect the individual changes if you use XML file) ?

Will it support a federated namespace or everything will be agregated into
a XML file?

If you want to use Corba/IDL, how it will be different from the existing
services for management or naming (that solve the same problem) ? 
How it will be different/better from existing Java APIs that deal with
management ( JMX ) or with naming ( JNDI ).

> > 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.

Sure, but Tomcat ( as a client ) will need to use a clear API to access
the service. That's missing. Even if it's a "generic" API, it still have
to be defined, to have some methods that can be called.

> > - 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.

Well, JNDI is the Java way to access directory services. There are C APIs
for that, Perl APIs for that, etc. If the _API_ will be based on a
namespace, it would be a bad ideea to invent another way for Java. 

> > 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).

Wait! Do you mean "take the data out of LDAP and create a XML file" ???
Then you loose all advantages of LDAP... You'll need to invent a new
replication protocol ( in case you have multiple servers ), and add a
security layer that will be hard to enforce. ( in LDAP you can define
users and permissions at the context level - while in a XML file you
can't specify that a certain tag is readable only be a certain user).
You also loose the event notification in LDAP.

And it will be very un-natural - take the data out of a structured
repository, create a XML file, then parse the XML file. 

It's like "take all the data out of DNS and create a /etc/hosts.xml, and
have all applications read the hosts.xml file".
Or for user authentication, fetch the data out of NIS/radius/tacacs and
create a /etc/passwd.xml 

> > 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.



View raw message