tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Todd <>
Subject Re: config diag, etc
Date Wed, 04 Aug 1999 20:29:34 GMT

comments included.

hope this helps,


Troy Poppe wrote:
> 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.

my thoughts on security was, assuming http/s cgi compliant protocol,
use a cookie or url-rewriting scheme (hence the servlet "candidate
implemenation" bubble in the config service quadrant).

with such a scheme, clients can identify themselves with traditional
url encoded form data and/or digital certificates to manage the
"identity" aspect of security and the transmission could be conducted
over https to manage the "integrity" aspect of security.

if/when we go with alternative means by which to interact with
a config service we'll need to understand and address the security
issues specific to that protocol.

i'm a proponent of and experience with http/s with server side
processing (in java as a candidate implemenation). i can help
flesh out this perspective ... well, i pretty much have been
advocating the http/s cgi-compliant service processing xml formatted
data from day one but i have entertained and tried to understand/
address other perspectives as well.

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

i believe there is concensus that the initial format should be
xml/dtd initially while looking at using alternative xml formats
(eg rdf, schema) as appropriate. bigger picture, i believe we can
support "pass through" and translations of data on the "config
service" side of the equation but my hunch is that at the offset
it is best to leave data translations to the clients. put another
way, i don't think we necessarily want to create a "config rosetta
stone" service at the early stages.

> - Troy
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message