Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <3793B7A7.D800133B@eng.sun.com>
Date: Mon, 19 Jul 1999 16:41:27 -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: <3792E4C6.490C98D6@eng.sun.com> <3793AA99.C2DDD6F@mortbay.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


i completely agree. the "100% pure java" perspective was
taken, possibly prematurely, whilst a bit of "you can't
rewrite how apache does it's config" discussion was going
on ... which was not my intention at all.

i believe to preclude servers written in less then 100% pure
java from this service is technically not mandatory and i'll
try to reflect this accordingly.

regarding drill down content ... there is no way that i
solely can author all this stuff. i have ideas and i think
i have a 50k foot view of a "best fit scenario and a first
milestone definition" in mind but i welcome/encourage/beg
multi-author contributions on this thread ... as long as we
can continually progress in refining the scope (all be it
possibly big) and subsequent design decisions pertaining to
this initiative. i really don't want to hack in some
implementation early on that causes us to go through unnecessary
contortions later on which we could've seen early had we
pulled together some sort of "agreeable roadmap."

once we get a bit more shared document management (eg
cvs managed web content) this should be trivial. till then,
we'll have to make do. i can aggregate this stuff till
then (as editor, hence the Editor's Note nomenclature)
and i plan on continuing to add content as one author.

regarding the alias, it was recommended to me back when
to move this discussion to tomcat-dev@jakarta.apache.org
which is a move i feel very comfortable with.

that said, i'll roll in your comments and we'll proceed
accordingly ... k?

hope this helps,

-james

Greg Wilkins wrote:
> 
> James Todd wrote:
> >         attached is a first cut at collecting the various
> >         thoughts surrounding a "pure java http server
> >         configuration" project.
> 
> James,
> 
> A good start to formalizing these discussions, but a number
> of suggestions
> 
> The language/terminology of the document is firmly directed at
> configuration of a 100% java HTTP server.   It may be
> better to adjust the language to be a little more
> deployment nuetral and in line with the project definitions
> we have seen to date.   For example, it is probably worthwhile
> to structure the "Data Consumer Model" section along the lines of
> 
> Jakarta module configuration
>   |
>   + Jakarta Communciations connector configuration
>   |  + Adaptor configuration
>   |  |   + Apache
>   |  |   + Netscape
>   |  |   + ...
>   |  + HTTP Server config
>   |
>   + Servlet Container configuration
>   |  |
>   |  + Servlet Configuration
>   |  |   + JSP Servlet Configuration
>   |  |   + CGI Servlet Configuration
>   |  + ???
>   |
>   + New and wonderful module configuration
> 
> Configuration of a HTTP server is only one aspect of configuring
> "Jakarta"
> 
> Note that I think all configuration should be module based and
> all jakarta modules should share a common set of params. As much
> of jakarta will be dynamic and hopefully restartable, things like
> module name, CLASSPATHs and class loaders for each module
> should be common.
> 
> While I think you document does make the distinction between the
> configuration model, it's flat file format and the service that
> provides configuration - It think the distinctions need to be
> made clearer:
> 
>  + As Craig has suggested, we need to talk about the services
>    that provide configuration and their dynamic behaviour.
>    I see a mechanism similar to a window redraw API. The service
>    can tell us exactly what has changed in the config file (the region),
>    and config clients have the option of just refreshing that part of
>    the config, or giving up and refreshing the whole module.
> 
>  + As somebody else pointed out - the call to go XML has not
>    yet been made - so it is important to clearly separate
>    the data model from potential file formats.  Again this
>    will require work on the API so that it is decoupled from
>    any XML package.
> 
> You doc does cover these points - but I think a lengthy configuration
> architecture and philosophy statement is needed up front (including
> the protocol and management architecture etc.).  I'm happy either
> to contribute to this if James continues as primary author - or
> write a first draft if my ramblings here a along the lines of
> what others are thinking...
> 
> regards
> 
> --
> Greg Wilkins<gregw@mortbay.com>          GB  Phone: +44-(0)171-4394045
> Mort Bay Consulting Australia and UK.    Mbl Phone: +44-(0)7775534369
> http://www.mortbay.com                   AU  Phone: +61-(0)299772395
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org