- From: Tom Clarke <tclarke@agency.com>
- Date: Mon, 12 Jul 1999 12:29:20 -0400
- To: <general@jakarta.apache.org>
- Cc: "Eric Prud'hommeaux" <eric@w3.org>, "Daniel Lopez Ridruejo" <ridruejo@bart.us.es>
I have never liked the exposed strong separation of the Servlet engine from the webserver. (From an application design point of view the separation is a very useful thing, just not something that should necessarily be exposed) As a user I would like to be able to configure Apache, and not worry too much about what specific pieces of code I was actually configuring. I certainly don't want to have to deal with multiple configuration mechanisms. IMHO what is needed is a configuration mechanism which is extensible enough to allow sophisticated server extensions (i.e. like Jakarta) to be configured (by delegating appropriate parts of the configuration), but integrated enough to allow easy configuration and set-up. Any thoughts? Tom Tom Clarke Senior Technical Consultant AGENCY.COM V 212.358.2798 ----- Original Message ----- From: <ebayeh@us.ibm.com> To: <general@jakarta.apache.org> Cc: <general@jakarta.apache.org>; Eric Prud'hommeaux <eric@w3.org>; Daniel Lopez Ridruejo <ridruejo@bart.us.es> Sent: Monday, July 12, 1999 11:56 AM Subject: Re: Jakarta/Apache XML/RDF configuration file format(s) > > > > Stefano, > > We are currently defining an XML schema (DTD) to configure the Websphere > Application Server Web (Servlet and JSP) engine... I don't want to invent > something unique to IBM if we can use (or corraborate) on a standard Schema. I > will be happy to post our first pass at a DTD if anyone is interested. > > For web applications, we will use the standard schema posted in the 2.2 spec. > > > Cheers, > -Elias > > Chief Programmer, Architect, > IBM WebSphere Application Server > > (919) 254- (tie 444) 9179 (Office) > (919) 696-3390 (Pager/Cell) > net.Meeting address (audio/video): elias.raleigh.ibm.com > > "Simplicity is often the result of profound thought" > > > > > Stefano Mazzocchi <stefano@apache.org> on 07/12/99 06:00:44 AM > > Please respond to general@jakarta.apache.org > > To: general@jakarta.apache.org > cc: "Eric Prud'hommeaux" <eric@w3.org>, Daniel Lopez Ridruejo > <ridruejo@bart.us.es> (bcc: Elias Bayeh/Raleigh/IBM) > Subject: Re: Jakarta/Apache XML/RDF configuration file format(s) > > > > ---------------------------------------------------------------------------- ---- Dan Brickley wrote: > Is the detail of the XML format finalised, or up for discussion? There > was some talk last autumn of an XML/RDF representation of Apache > configuration files. A little history might help: During the ApacheCon '98 party at the SF Exploratorium (in October), Eric and I talked a lot about XML and the new stuff the W3C was creating. Eric is a very smart guy and we shared lots of ideas about how the web was going and how we could use those new technologies to do better things. (Some of that very early discussion made me create Cocoon a few months later to investigate it further, but this is another story). We both agreed that XML was a major move forward and given its simple-yet-powerful syntax and structure, it could really be used for XML configurations (at that time, some of the Apache folks were not satisfied by the three-files Apache configurations and wanted to move forward for Apache 2.0. XML was proposed as a choice) and all a bunch of other things. At the same event, Daniel was showing its new Comanche and showed me how he had some "configuration wrappers" that allowed its engine to be very flexible and abstracted on the real configurations. (we had discussed this privately the summer before when I was trying to start off a new Swing-based configuration project for JServ under java.apache called "Jack - Java Apache Configuration Kit" but went nowhere). It was simple to associate this meta-configuation separatation model with what the W3C was doing. So Erid, Daniel, Pierpaolo and I spent a whole afternoon to find out the best way to do it. (Eric later set up the mail list you were indicating). As you see, those ideas have been around for a while and if we move Jakarta into the configurations-in-XML world, this is something we should seriously investigate since it would allow people (and vendors) to contribute with such configuration tools in a very abstracted way. Here is a simple configuration file to show what I mean: <server> <name>jakarta.apache.org</name> <port>80</port> <admin>jakarta@apache.org</admin> </server> Given the configuration DTD, you might use XML tools (such as IBM Xeena) to edit these elements in a valid way, but DTD are very limited because they validate the XML structure and not the internal rules. So you need to come out with something that allows a configuration tool (might be GUI or text based) a way to present information in an interactive way (use TextField or ComboBox, etc..) and to validate it against some strict rules (1 < port < 64K, admin content is a valid mail address, etc..) If all this information is based on a common meta-configuration definition language (Eric thought about RDF for this, but I don't know RDF enough to express a final opinion on this), then one tool may be used to configure every possible software that can express such RDF for its configurations. This is so flexible (being on different files) that old vi-style people are not bothered by unnecessary information in their XML configuration file, but people willing to use more coherent tools (such as Comanche) for different software in their network. This tool might also be nicely wrapped by SNMP logic and so on. The key point is the separation of configurations (in XML with some DTD) parsed by the configured software and meta-configurations (in another XML using the RDF DTD) parsed by whatever configuration tool. An important thing is that meta-configurations are used as "templates" for the creation of an XML configuration and might even be used by installers to present interactive information to the user during installation. For example (I'm not using RDF for this, just to show my intentions): <element name="port" required="true"> <template-value>80</template-value> <gui type="counter"> <comment xml:lang="en">This is the port used by the server</comment> <comment xml:lang="it">Questa č la porta usata dal server</comment> <comment xml:lang="fr">Cette est la porte utilisče par le serveur</comment> </element> as you see, a configuration tool that is able to interpret this document would be able to generate the <port> element and query the user (depending on its language). Unfortunately, the list is dead for some time now. But the ideas, IMO, as still solid and useful. P.S. Eric, Daniel, sorry to make you jump on this. For more information about Jakarta, look at jakarta.apache.org. Send any comment to me and I'll forward to the mail list (or you might consider to subscribe to the list if interested) -- Stefano Mazzocchi A language that doesn't affect the way you think about programming, is not worth knowing. <stefano@apache.org> Alan J. Perlis --------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org For additional commands, e-mail: general-help@jakarta.apache.org ---------------------------------------------------------------------------- ---- > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org > For additional commands, e-mail: general-help@jakarta.apache.org
Received on Monday, 12 July 1999 15:42:19 UTC