tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Todd <james.t...@eng.sun.com>
Subject Re: config diag, etc
Date Wed, 04 Aug 1999 17:07:00 GMT

comments included.

hope this helps,

- james

"Carreira, Jason" wrote:
> 
> > -----Original Message-----
> > From: James Todd [mailto:james.todd@eng.sun.com]
> >
> > i echo. well stated. i did not draw "protocols" supported but
> > i kind of assumed when one was interacting with a jsp and/or
> > servlet interface it was understood that it was over http and
> > as such the client could be impelmented in any flavor. rmi is
> > more java-centric but could possibly be wrapped with an orb
> > (or the underling objects) to play in an open object request
> > scenario. jndi is indeed a java play. are there other "service
> > protocols" that should be considered?
> >
> 
> Perhaps, since there is a general feeling that this config service not only
> needs to be accessed by apps in other languages, but also needs to be
> implementable in other languages, we should first work on a CORBA IDL for
> the config API, then work out a reference implementation of the API in java.
> To the reference impl we could add RMI and JNDI hooks that would be outside
> the scope of the API (which would be the IDL) but put there to hook more
> easily into java clients/tools... There could also be a separate API for
> http/s clients/tools to interface with the config service that would also be
> back-end-implementation independent, although I'm not sure how such can be
> codified...

agreed. if the boundaries (client, service, data) are endorsed
then i think we should start fleshing out the api protocols and
message formats.

i feel the "path of least resistence" may be:

	http/s interface to cgi compliant service
	serving up ascii text

a "possible" implemenation of this is:

	servlet responding to stateful (eg cookies, session)
	requests for configuration data which is served as
	xml format

a bit more coupled (and this is not to say that it is necessarily
bad) is, as you have stated, a corba interface to which a possible
implemenation could be an rmi service interacting with, possibly,
some of the same config processing logic as the afore mentioned
http/cgi methodology.

there are many more options which may or may not be attractive
but are none the less viable, as i see it, and should therefore
be addressed ... but i think some baselines should be drawn. at
this point it looks to be:

	http/s to cgi compliant service

	corba (i claim ignorance on this one)

i do see an implemenation where by these protocol handlers
could attach to a single config manager layer. to me, this
looks attractive.

> 
> This would allow us to build the implementation without worries about Apache
> standalone users not wanting to start up a JVM for the config service... it
> could be implemented in C/C++ if necessary...

yep. btw, the other day someone mentioned that a jvm may not
present on many target platforms. if we go with http/s to cgi
compliant service then perhaps this concern can be addressed.
i'd also like to offer that tomcat runs on the following development
platforms:

	solaris (sparc, intel)
	win (9x, nt)
	apple (?8?)
	linux (?)

although i'm not sure of the os version/jdk specifics.

> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Mime
View raw message