You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by James Todd <ja...@eng.sun.com> on 1999/07/15 03:09:43 UTC
Re: Apache Configuration - was I volunteer!]
<wonderingMyResponseIsn'tReflectedInTheList>
repost, what's up with this???
</wonderingMyResponseIsn'tReflectedInTheList>
-------- Original Message --------
Subject: Re: Apache Configuration - was I volunteer!
Date: Wed, 14 Jul 1999 17:47:22 -0700
From: James Todd <ja...@eng.sun.com>
Organization: Sun Microsystems
To: general@jakarta.apache.org
References: <DC...@USAMCMS2>
<m3...@tildeslash.com>
Jan-Henrik Haukeland wrote:
>
> Let me just add this also: To give servlets real momentum, IRL, one
> _must_ get as many ISP's as possible to host them. And since most of
> the bigger ISP's still are using Unix (thank God!), you have to talk
> your average Unix system admin (aka bofh) into hosting servlets. It
> will be bad enough when he sees the XML config files (but he's used to
> sendmail.cf so he'll maybe, just maybe let it pass), but when he see
> the applet's it's game over. And if the Servlet Engine comes with a
> java install-shield (like WebSphere) it's realy game over.
>
agreed ... what about a framework/architecture whereby
the config info can be accessed and manipulated by a
variety of cooperative means, eg:
edit config file directly
stop server
edit file with your favorite editor (ed to ie)
start server
html form/jsp/servlet/config file
interacts with the very same config file
mentioned above and does not disrupt
said process
applet/jsp/servlet/config file
some of the same logic used in the
previous approach can be re-used
here ... only the "view" changed a
bit. the key here is the applet
should interact with the core server
side config logic/service
rmi/config file
remote hooks to server side config
logic/service
applet/rmi/config file
ditto ... just another view
ldap/config file
kind of like a broken record at this point
but the idea is if designed/factored
appropriately we have compelling options
serialized object|xml construct/servlet/config file
this is an interesting way for loose coupling
(very)remote access (note: add in pki/ssl as
well)
there are others ... the key as i see it is that i
don't think the goal should be one or the other but
how can this be designed so that options, should it
be desired, abound.
- james
Re: Apache Configuration - was I volunteer!]
Posted by Alexander Jesse <Al...@Credit-Suisse.ch>.
I would add another setup option
- make changes using ANY gui to a development/test server
- reconfig that server
a) by restart
b) by a signal-type runtime action
- create
c) a script to do the same modifications to another server
d) an input file for a batch-utility/script to modify other
servers' config
between a) and b) I prefer b)
between c) and d) I prefer d) (gives me the possibilities to
write a little utility/script for a new platform. Or even
a servlet which can read this file (via upload...) and change
its own servers config -> remote operation)
What does it give me:
- an easy and controlled way to configure a single server
- the possibilites to mirror these changes to other servers
(might please the Win$$$-type admin as well as the "ed"-loving
*nix guy)
If I can help in this area: count me in
Alexander Jesse
(former Sys-Prog on tiny to BIG iron)
===========================================================
James Todd wrote:
>
> <wonderingMyResponseIsn'tReflectedInTheList>
> repost, what's up with this???
> </wonderingMyResponseIsn'tReflectedInTheList>
>
> -------- Original Message --------
> Subject: Re: Apache Configuration - was I volunteer!
> Date: Wed, 14 Jul 1999 17:47:22 -0700
> From: James Todd <ja...@eng.sun.com>
> Organization: Sun Microsystems
> To: general@jakarta.apache.org
> References: <DC...@USAMCMS2>
> <m3...@tildeslash.com>
>
> Jan-Henrik Haukeland wrote:
> >
>
> > Let me just add this also: To give servlets real momentum, IRL, one
> > _must_ get as many ISP's as possible to host them. And since most of
> > the bigger ISP's still are using Unix (thank God!), you have to talk
> > your average Unix system admin (aka bofh) into hosting servlets. It
> > will be bad enough when he sees the XML config files (but he's used to
> > sendmail.cf so he'll maybe, just maybe let it pass), but when he see
> > the applet's it's game over. And if the Servlet Engine comes with a
> > java install-shield (like WebSphere) it's realy game over.
> >
>
> agreed ... what about a framework/architecture whereby
> the config info can be accessed and manipulated by a
> variety of cooperative means, eg:
>
> edit config file directly
>
> stop server
> edit file with your favorite editor (ed to ie)
> start server
>
> html form/jsp/servlet/config file
>
> interacts with the very same config file
> mentioned above and does not disrupt
> said process
>
> applet/jsp/servlet/config file
>
> some of the same logic used in the
> previous approach can be re-used
> here ... only the "view" changed a
> bit. the key here is the applet
> should interact with the core server
> side config logic/service
>
> rmi/config file
>
> remote hooks to server side config
> logic/service
>
> applet/rmi/config file
>
> ditto ... just another view
>
> ldap/config file
>
> kind of like a broken record at this point
> but the idea is if designed/factored
> appropriately we have compelling options
>
> serialized object|xml construct/servlet/config file
>
> this is an interesting way for loose coupling
> (very)remote access (note: add in pki/ssl as
> well)
>
> there are others ... the key as i see it is that i
> don't think the goal should be one or the other but
> how can this be designed so that options, should it
> be desired, abound.
>
> - james
>