Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <37953417.A2485A91@eng.sun.com>
Date: Tue, 20 Jul 1999 19:44:39 -0700
From: James Todd <james.todd@eng.sun.com>
Organization: Sun Microsystems
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: Re: request for review: server/config discussion
References: <DC37797EB8C3D21197280008C74C893DF119A3@USAMCMS2>
 <3794DCB6.D7A9872E@eng.sun.com> <3794E650.D038BB6A@algroup.co.uk>
 <3794EE1F.A98D643B@eng.sun.com> <19990720183708.B31037@usite.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Troy Poppe wrote:
> 
> > it could be that an api is provided via the service to "check"
> > the freshness (born on date) of the data and leave it up to
> > the client (eg server) to do with what it may with the results.
> > another passive means might be to throgh some sort of exception
> > indicating that "data you've obtained from me has since been
> > modified."
> 
> I like this idea of the server becoming the client for its own
> configuration (that is what you are saying right? :)).  Meta-configuation
> perhaps?
> 

i believe that is a possibility ... a "generalized" configuration
service can come into play and the owner/operator of the service
can choose, at least in the early rounds, on how closely to bind
this service with the user entity (eg http server). in the early
states i think we should error on the side of "make it simple"
(in this specific case passive notification).

i'm going to go on a bit'o pieInTheSky here for a moment so please
bear with me (and please don't loose faith that i'm not tracking
the details necessary to get us from "talk to walk").

i see a couple of dimensions unfolding here and, while i prefer
to keep things simple in the early stages so that we can start
proto-typing some of the these concepts, we should still strive
to aim high, a possible target being:

	if the "config service" supports http as one communication
	protocol (lots of good reasons to do this)

	it will need to rely on an http server (or embedded
	server)

	a smallish and pure 100% java server, such as tomcat,
	can most likely fit the bill here (i'm sure there are
	others but i'd aim for bare bones at this point ...
	sides, the server should/could be pluggable ... but i'm
	a proponent of tomcat for the first go 'round)

	the server the "config service" relys on itself might
	perhaps require a config service ... which might be a
	expressed as a ?very? similiar config service we're
	talking about today ... possibly bound in a bit tighter
	to the config service proper ... possibly not ... as it
	is all just a service at one level ... it is just an
	instantion ordering difference

that is the pontential ... errrr ... one of the possible potentials
should this puppy (api and protocol) is mapped out a bit.

my thoughts anyways,

- james