tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan-Henrik Haukeland <h...@tildeslash.com>
Subject Re: config diag, etc
Date Mon, 09 Aug 1999 23:02:45 GMT
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

Mime
View raw message