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 19:09:35 GMT
On Wed, Aug 04, 1999 at 11:53:50AM -0700, costin@dnt.ro wrote:
> 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. 

We haven't gotten this far, but we really need to start, as James Todd
has said.

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

Most likely both, as more options at the outset aren't bad.

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

I think we need to support both of these.  It seems to me that it'd be nice to
have event notification, but also is necessary to have polling ability (with
checking (ie. diffs) done on the client side).

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

Good question.  And I don't know the answer.

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

Again, good question, one I can't answer yet.

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

As I said above, we need to start working on an API.  Defining that API is
the goal of this discussion.

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

Yep, but that has to be decided.

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

No, what I was thinking here is that the LDAP entry for a certain configuration file
contain the appropriate XML, not generate it.

As for security, I'm assuming that we're going to implement some sort of authentication
mechanism for this service (right James?) to restrict WHO can configure themselves
off a specific instance of the service.  There'd have to be some pass-through authentication
done with respect to LDAP and any other data store for that matter.

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

This hasn't been decided yet either.... There was a bit of discussion, and I don't
remember a resolution to this. (was there?)

- Troy

Mime
View raw message