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 Tue, 10 Aug 1999 17:47:50 GMT

for what it is worth, i'm completely on the same page. i
don't want to unintentionally preclude using some ?advanced?
api's as time permits (hence my 1-pager) but i do think
we have critical mass to start fleshing this little gig
out with some "out-of-the-gate" principles and first deliverables.

i'm all for patterns. i agree with your recommended narrowed
use of uml. i tend to draw the "rolled up class diagrams" (not
sure what it is actually called) and not worry too much about
gettting all the fields right or cardinality nailed down initially.

here's a recap of what i think are the initial ?constructs?
we're aiming for:

	http - to - cgi (eg servlet) service

		focus on "get" requests initially
		(eg client obtains read-only config
		data)

		data format could be:

			xml (not necessarily the same xml
			format as defined by the config file)

			serialized objects

	config manager/broker process (logic)

		config reader (url, xml parser)

	xml config format (dtd)

this should be the bare minimum yet provided a pretty
compelling bang-for-the-buck perspective.

within tomcat, there is a light-weight "startup" program
which effectively is acts a a tightly coupled config broker.
it uses the ProjectX parser distributed by sun at the moment.
as i see it, this piece of logic could be factored out to a
"client independent" broker service quite readily.

cool,

- james

Jan-Henrik Haukeland wrote:
> 
> James Todd <james.todd@eng.sun.com> writes:
> 
> > +1
> 
> lol
> 
> > i like using uml diags for the very reasons your suggesting ...
> > as a visual discussion point with which we can begin to
> > formulate the grandest of plans. i don't use uml to document
> > every detail of a system and i typically (as martin fowler
> > points out in "uml distilled") only use 5% of the syntax and
> > i don't worry about getting it 100% correct either.
> 
> That's how we've been using UML as well, and with good experience. May
> I suggest that we limit ourself to using only the class diagram
> perspective, and skip the process diagram and such. And a class
> diagram is so simple that everyone should be able to understand it.
> 
> IMHO UML helps tremendously as a concept distributing vehicle in a
> project (oh that was a mouthful) and I'm sure it's going to be very
> usefull in this project as well. Especially with so many involved.
> 
> > i do see "one path" in the 1-pager with which we can start
> > proto-typing these ideas. that's what i'm actually eager to see
> > happen but i would like to see a bit of design discussion continue
> > as "config mgmt" is a pretty big, but not necessarily complex,
> > puppy.
> 
> The path to nirvana is eightfold I belive ;) but it's good to start on
> one. But I agree absolutely with doing some more fine thinking around
> the design first. Maybe we could try to apply some patterns for how
> the api is designed?
> 
> I'm just thinking aloud here (and probably not very good either, since
> the thinking just started when I write this), say a combination of the
> Delegation and Factory pattern could maybe be used at the "interface"
> (i.e. protocol) layer. Since, as your diagram and as the discussion
> has shown, more than the HTTP protocol will be supported (in the long
> run at least).
> 
> Maybe something along the lines of using a Factory structure for
> creating Handlers for each protocol. The rational for this is if we
> are able to create a good generic structure (interface) here, new
> protocol handlers could be added later without changing the
> fundamental design. And where each handler Delegates actual config
> operations to a ConfigManager object. At the same time the handlers
> could be notified for changes in the ConfigModel (used by the
> ConfigManager) by implementing a event listener interface. Events
> could then propagate from a handler to it's clients. (In the HTTP case
> a client would be a servlet). Of course this is more or less what you
> guys already have modeled, just bringing in the pattern aspect here.
> 
> Such a structure (the api structure) would be good to model in an UML
> diagram, I think.
> 
> > a pretty good piece of the backend xml processing will be available
> > with the tomcat code drop.
> 
> So tomcat already has a XML parser available for use?
> 
> Ps. Speaking of UML BTW, here is a good satirical article:
> http://www.eiffel.com/doc/manuals/technology/bmarticles/uml/page.html
> It's always good to be critical to hyped up things, but in this case I
> belive that some parts of UML is good (i.e. class diagrams)
> 
> --
> Jan-Henrik Haukeland
> 
> ---------------------------------------------------------------------
> 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