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 Mon, 09 Aug 1999 18:53:30 GMT

+1

completely agreed.

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.

it would be cool if we could use the same tool or find a set
of tools that can manipulate a common graphics format so that
we can collaborate on the diags. troy and i have started this
a bit using vThought (www.confluent.com). i like this tool
but am open to trying others.

now, the 1-pager i threw on the table is indeed implemenation
specific and is where i feel we could/should head with respect
to "config management" taking advantage of a set (not a singular)
api's and protocols. the 1-pager is also to convey how i see
leveraging a collection of complimentary solutions if we break
things up appropriately (ie the "config service broker"). that
said, if we do agree on some basic principles, 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.

> From there on we could take on the systems process aspect by creating
> a thin prototype api-layer and a servlet using that layer. In this
> phase, I personally feel that an UML diagram would have been nice to
> have. Just to sync everybody.

!oh yeah! i pretty good piece of the backend xml processing
will be available with the tomcat code drop. host this behind
a servlet is exactly the next step i'd like to see happen. if
done right, the other layers could come onto the scene at the
right time with little disruption.

hope this helps,

- james



Jan-Henrik Haukeland wrote:
> 
> Here's a snip from Eric Raymond's "The Cathedral and the Bazaar",
> where he quotes Fredric Brooks,
> 
>  ``Show me your [code] and conceal your [data structures], and I shall
>  continue to be mystified.  Show me your [data structures], and I
>  won't usually need your [code]; it'll be obvious.''
> 
> And I'll guess we all are a bit mystified by this config. discussion,
> at least I am. And IMHO I think we should start with the systems
> structure before going on to the systems process aspect.
> 
> I feel then that James is doing the right thing, that is with his rfd
> document (http://java.sun.com/people/gonzo/tomcat/ConfigService.txt)
> Especially in chap. 3 and in the appendix where attributes that are
> necessary to operate the servlet engine, are described.
> 
> The diagrams on the other hand is interesting, but describes more the
> process aspect of the system. Right now could we not just agree on this:
> 
> James Todd <james.todd@eng.sun.com> writes:
> 
> >       http/s - cgi compliant service - xml formatted static data
> >
> > as a bare minimum.
> 
> and then let LDAP, Corba and what not just rest for a while?
> 
> As a constructive suggestion could we compare James rfd's attributes
> with the properties necessary to operate JServ 1.1 and maybe come up
> with a minimum attribute set we will need to operate an engine ?
> 
> (While tomcat and it's source-code right now has taken on a more
> mytical character, we have Craig's Jserv 1.1 with source code and
> everything.)
> 
> Then we could create a bare minumum xml-config file, without any
> presentation stuff.
> 
> From there on we could take on the systems process aspect by creating
> a thin prototype api-layer and a servlet using that layer. In this
> phase, I personally feel that an UML diagram would have been nice to
> have. Just to sync everybody.
> 
> What do you think?
> 
> --
> 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