From jose88@example.org Sun Oct 10 20:53:01 1999 Return-Path: <jose88@example.org> Mailing-List: contact jose88@example.org; run by ezmlm Delivered-To: mailing list jose88@example.org Received: (qmail 3623 invoked by uid 2016); 10 Oct 1999 20:53:01 -0000 Delivered-To: jose88@example.org Received: (qmail 3612 invoked by uid 247); 10 Oct 1999 20:53:00 -0000 Date: 10 Oct 1999 20:53:00 -0000 Message-ID: <jose88@example.org> From: jose88@example.org To: jose88@example.org Subject: cvs commit: jakarta-tools README duncan 99/10/10 13:52:59 Modified: . README Log: Added description to jakarta-tools readme. This is really more of a test to make sure that checkins are working correctly Revision Changes Path 1.2 +6 -2 jakarta-tools/README Index: README =================================================================== RCS file: /home/cvs/jakarta-tools/README,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- README 1999/10/09 00:05:53 1.1 +++ README 1999/10/10 20:52:59 1.2 @@ -1,4 +1,8 @@ -$Id: README,v 1.1 1999/10/09 00:05:53 duncan Exp $ +$Id: README,v 1.2 1999/10/10 20:52:59 duncan Exp $ This is the source code repository for the various tools used by The -Jakarta Project. +Jakarta Project. These tools include: + + Ant: Java based build system + Moo: Java based client / server test harness + From jose88@example.org Mon Oct 11 02:42:38 1999 Return-Path: <jose88@example.org> Mailing-List: contact jose88@example.org; run by ezmlm Delivered-To: mailing list jose88@example.org Received: (qmail 24163 invoked by uid 2016); 11 Oct 1999 02:42:38 -0000 Delivered-To: jose88@example.org Received: (qmail 24161 invoked by uid 259); 11 Oct 1999 02:42:37 -0000 Date: 11 Oct 1999 02:42:37 -0000 Message-ID: <jose88@example.org> From: jose88@example.org To: jose88@example.org Subject: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core Context.java costin 99/10/10 19:42:37 Modified: src/share/org/apache/jasper Options.java src/share/org/apache/tomcat/core Context.java Log: Fixed minor JDK1.1 problem in Jasper. Revision Changes Path 1.2 +9 -4 jakarta-tomcat/src/share/org/apache/jasper/Options.java Index: Options.java =================================================================== RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/Options.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- Options.java 1999/10/09 00:20:34 1.1 +++ Options.java 1999/10/11 02:42:32 1.2 @@ -1,7 +1,7 @@ /* - * $Header: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/Options.java,v 1.1 1999/10/09 00:20:34 duncan Exp $ - * $Revision: 1.1 $ - * $Date: 1999/10/09 00:20:34 $ + * $Header: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/Options.java,v 1.2 1999/10/11 02:42:32 costin Exp $ + * $Revision: 1.2 $ + * $Date: 1999/10/11 02:42:32 $ * * ==================================================================== * @@ -102,7 +102,7 @@ * I want to see my generated servlets. Which directory are they * in? */ - public File scratchDir = new File(System.getProperty("java.io.tmpdir")); + public File scratchDir; /** * Need to have this as is for versions 4 and 5 of IE. Can be set from @@ -159,6 +159,11 @@ * ServletConfig and ServletContext. */ public Options(ServletConfig config, ServletContext context) { + // XXX it will be overriden latter, and JDK1.2 specific. + // can we remove it? + String scratchDirName=System.getProperty("java.io.tmpdir"); + if( scratchDirName != null ) + scratchDir = new File(scratchDirName ); String keepgen = config.getInitParameter("keepgenerated"); if (keepgen != null) { if (keepgen.equalsIgnoreCase("true")) 1.2 +4 -3 jakarta-tomcat/src/share/org/apache/tomcat/core/Context.java Index: Context.java =================================================================== RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Context.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- Context.java 1999/10/09 00:30:01 1.1 +++ Context.java 1999/10/11 02:42:36 1.2 @@ -1,7 +1,7 @@ /* - * $Header: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Context.java,v 1.1 1999/10/09 00:30:01 duncan Exp $ - * $Revision: 1.1 $ - * $Date: 1999/10/09 00:30:01 $ + * $Header: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Context.java,v 1.2 1999/10/11 02:42:36 costin Exp $ + * $Revision: 1.2 $ + * $Date: 1999/10/11 02:42:36 $ * * ==================================================================== * @@ -926,6 +926,7 @@ try { result.getWrapper().loadServlet(); } catch (Exception ee) { + ee.printStackTrace(); String msg = sm.getString("context.loadServlet.e", servletName); From jose88@example.org Mon Oct 11 13:47:52 1999 Return-Path: <jose88@example.org> Mailing-List: contact jose88@example.org; run by ezmlm Delivered-To: mailing list jose88@example.org Received: (qmail 26132 invoked from network); 11 Oct 1999 13:47:52 -0000 Received: from eastwood.aldigital.algroup.co.uk (83.161.120.155) by apache.org with SMTP; 11 Oct 1999 13:47:52 -0000 Received: from freeby.ben.algroup.co.uk (freeby.ben.algroup.co.uk [83.161.120.155]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id NAA20654; Mon, 11 Oct 1999 13:46:45 GMT Received: from algroup.co.uk (naughty.ben.algroup.co.uk [83.161.120.155]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id OAA25716; Mon, 11 Oct 1999 14:47:00 +0100 Message-ID: <jose88@example.org> Date: Mon, 11 Oct 1999 14:46:44 +0100 From: Ben Laurie <jose88@example.org> Organization: A.L. Group plc X-Mailer: Mozilla 4.7 [en] (WinNT; I) MIME-Version: 1.0 To: jose88@example.org, Tomcat Development <jose88@example.org> Subject: Re: XML configuration revisited References: <jose88@example.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Pratik Patel wrote: > > Greetings, > > I was looking through the archives for this list when I started reading > about the XML configuration discussion. > Has any work been done on this, and is there an DTD (even a rough one) > that someone has already created? We would like to build a DTD that > incorporates the new Java Servlet API's specification on web > applications (http://java.sun.com/j2ee/dtds/web-app_1_2.dtd) with an > Apache configuration DTD. > > Our idea at this point is to build a simple DTD that incorporates both > the Apache config details and the future web.xml DTD. For the time > being, we will edit the XML config by hand and write a simple parser to > spit out httpd.conf and jserv.conf/jserv.properties/servlets.properties. > We would like some feedback and see if anyone else is already working on > this, possibly as part of Jakarta. It has been discussed on the Tomcat mailing list, but so far without much in the way of conclusions. The major issue I see is that Apache's configuration is extensible, but DTDs are not (at least, as far as I understand them). So, some kind of XDTD (to coin an acronym) is needed. I believe such things do exist, but I don't know much about them. However, the fact that they are plural worries me :-) Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi From jose88@example.org Mon Oct 11 18:25:49 1999 Return-Path: <jose88@example.org> Mailing-List: contact jose88@example.org; run by ezmlm Delivered-To: mailing list jose88@example.org Received: (qmail 15284 invoked from network); 11 Oct 1999 18:25:49 -0000 Received: from mercury.sun.com (83.161.120.155) by apache.org with SMTP; 11 Oct 1999 18:25:49 -0000 Received: from engmail4.Eng.Sun.COM ([83.161.120.155]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA14848; Mon, 11 Oct 1999 11:25:27 -0700 (PDT) Received: from taller.eng.sun.com (taller.Eng.Sun.COM [83.161.120.155]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id LAA15841; Mon, 11 Oct 1999 11:24:41 -0700 (PDT) Received: from eng.sun.com by taller.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA06733; Mon, 11 Oct 1999 11:24:40 -0700 Message-ID: <jose88@example.org> Date: Mon, 11 Oct 1999 11:25:37 -0700 From: James Todd <jose88@example.org> Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: jose88@example.org CC: jose88@example.org Subject: Re: XML configuration revisited References: <jose88@example.org> <jose88@example.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ben Laurie wrote: > > > It has been discussed on the Tomcat mailing list, but so far without > much in the way of conclusions. some conclusions have been formed ... they may not necessarily be universally embraced though. i personally have been hell'a busy for the last 2 months getting servlet 2.2 and j2ee in harmony and thusly have not been able to put time back into the config discussion. the issues is still very alive in my mind and my perspectives have not altered significantly. the discussions to date seemed to only go so far without code in hand ... which to be quite honet still baffles me ... but none the less i believe raising the bar on component/subsystem configuration is of importance. > > The major issue I see is that Apache's configuration is extensible, but > DTDs are not (at least, as far as I understand them). So, some kind of > XDTD (to coin an acronym) is needed. I believe such things do exist, but > I don't know much about them. However, the fact that they are plural > worries me :-) > i'd start bottom up and grow this organically. further i propose considering the configuration approach used by tomcat as a starting point as 1) it is simple and 2) it is based on xml and java and as such should be impervious of many platform specific concerns. now, by saying it is simple i am not implying that it will solve world hunger ... quite the opposite. if we can get subsystem (eg tomcat servlet container) configurations to become real and portable then hosting system configuration concerns becomes at some level just a matter of interacting and instrumenting the various subsystems configuration api. - james From jose88@example.org Mon Oct 11 18:30:14 1999 Return-Path: <jose88@example.org> Mailing-List: contact jose88@example.org; run by ezmlm Delivered-To: mailing list jose88@example.org Received: (qmail 20719 invoked from network); 11 Oct 1999 18:30:14 -0000 Received: from rod.gstis.net (HELO wenet.net) (83.161.120.155) by apache.org with SMTP; 11 Oct 1999 18:30:14 -0000 Received: from paris (cvx01-480.sfo.wenet.net [83.161.120.155]) by wenet.net (8.9.3/8.9.3) with SMTP id LAA03652; Mon, 11 Oct 1999 11:30:08 -0700 (PDT) Message-ID: <005901bf1416$a7558920$1609fea9@paris> From: "James Davidson" <jose88@example.org> To: <jose88@example.org>, "Tomcat Development" <jose88@example.org> References: <jose88@example.org> <jose88@example.org> Subject: Re: XML configuration revisited Date: Mon, 11 Oct 1999 11:30:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 > The major issue I see is that Apache's configuration is extensible, but > DTDs are not (at least, as far as I understand them). So, some kind of > XDTD (to coin an acronym) is needed. I believe such things do exist, but > I don't know much about them. However, the fact that they are plural > worries me :-) XML is extensible even if the DTD can be rigid. For example, in Ant (a little build tool that we are using over in Tomcat land), the first two levels of the config file are set, but the next level down is dynamically mapped to wherever it needs to go.. Let me give an example: The build.xml file is structured like: <project name="Tomcat"> <target name="main" depends="foo"> <[taskname] [taskattribute=value]/> </target> </project> The taskname is resolved to a class, and instance of that class is created and the attributes of the task are reflected into that class via beans setter methods to configure it. This lets us do the following: <project name="foo"> <taskdef name="newtask" class="org.apache.reallycool.TaskClass"/> <target name="main"> <newtask att1="foo" att2="bar"/> </target> </project> So at runtime, I've created extensibility on the fly using this. In ant, the definition of what the task tags can look like is driven by a set of defaults and added to by in xml taskdefs -- in some other application such as configuration -- the configuration could be read in a central location and only the various components interested in particular parts of the config file need ask for what they want. I'm sure that people who think that everything should have a DTD are going to choke over this approach, but it gives Ant amazing on the fly flexibility to deal with things, lets people writing the config files use a well defined easy to read common syntax, and lets the progam itself use standard XML libraries to do business. .duncan From jose88@example.org Mon Oct 11 18:49:09 1999 Return-Path: <jose88@example.org> Mailing-List: contact jose88@example.org; run by ezmlm Delivered-To: mailing list jose88@example.org Received: (qmail 12942 invoked from network); 11 Oct 1999 18:49:09 -0000 Received: from eastwood.aldigital.algroup.co.uk (83.161.120.155) by apache.org with SMTP; 11 Oct 1999 18:49:09 -0000 Received: from freeby.ben.algroup.co.uk (freeby.ben.algroup.co.uk [83.161.120.155]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id SAA04293; Mon, 11 Oct 1999 18:47:15 GMT Received: from algroup.co.uk (naughty.ben.algroup.co.uk [83.161.120.155]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id TAA27314; Mon, 11 Oct 1999 19:47:37 +0100 Message-ID: <jose88@example.org> Date: Mon, 11 Oct 1999 19:47:16 +0100 From: Ben Laurie <jose88@example.org> Organization: A.L. Group plc X-Mailer: Mozilla 4.7 [en] (WinNT; I) MIME-Version: 1.0 To: jose88@example.org CC: jose88@example.org Subject: Re: XML configuration revisited References: <jose88@example.org> <jose88@example.org> <jose88@example.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit James Todd wrote: > > Ben Laurie wrote: > > > > > > It has been discussed on the Tomcat mailing list, but so far without > > much in the way of conclusions. > > some conclusions have been formed ... they may not > necessarily be universally embraced though. i personally > have been hell'a busy for the last 2 months getting > servlet 2.2 and j2ee in harmony and thusly have not > been able to put time back into the config discussion. > > the issues is still very alive in my mind and my > perspectives have not altered significantly. the > discussions to date seemed to only go so far without > code in hand ... which to be quite honet still > baffles me ... but none the less i believe raising > the bar on component/subsystem configuration is of > importance. Actually, I don't think it was lack of code that stalled the discussion, but an embarassment of options on how to solve the "XDTD problem". > > The major issue I see is that Apache's configuration is extensible, but > > DTDs are not (at least, as far as I understand them). So, some kind of > > XDTD (to coin an acronym) is needed. I believe such things do exist, but > > I don't know much about them. However, the fact that they are plural > > worries me :-) > > > > i'd start bottom up and grow this organically. further > i propose considering the configuration approach used > by tomcat as a starting point as 1) it is simple and > 2) it is based on xml and java and as such should be > impervious of many platform specific concerns. Well, that's fine and dandy, but... > now, by saying it is simple i am not implying that > it will solve world hunger ... quite the opposite. > if we can get subsystem (eg tomcat servlet container) > configurations to become real and portable then > hosting system configuration concerns becomes at > some level just a matter of interacting and instrumenting > the various subsystems configuration api. ...I think that until you think about how to integrate subsystems you haven't addressed any problems that don't fall into the realm of the bleedin' obvious(tm). To take a really trivial Apache example, some modules have some configuration that can appear within <VirtualHost ...> sections, and some that can't. The XDTD should define this, rigorously. Somehow. Ideally in a way that everyone thinks is good and is standardised. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi From jose88@example.org Mon Oct 11 19:22:57 1999 Return-Path: <jose88@example.org> Mailing-List: contact jose88@example.org; run by ezmlm Delivered-To: mailing list jose88@example.org Received: (qmail 14477 invoked from network); 11 Oct 1999 19:22:57 -0000 Received: from mercury.sun.com (83.161.120.155) by apache.org with SMTP; 11 Oct 1999 19:22:57 -0000 Received: from engmail2.Eng.Sun.COM ([83.161.120.155]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA10719; Mon, 11 Oct 1999 12:22:35 -0700 (PDT) Received: from taller.eng.sun.com (taller.Eng.Sun.COM [83.161.120.155]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id MAA07137; Mon, 11 Oct 1999 12:22:32 -0700 (PDT) Received: from eng.sun.com by taller.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA12078; Mon, 11 Oct 1999 12:22:29 -0700 Message-ID: <jose88@example.org> Date: Mon, 11 Oct 1999 12:23:27 -0700 From: James Todd <jose88@example.org> Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: jose88@example.org CC: jose88@example.org Subject: Re: XML configuration revisited References: <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ben Laurie wrote: > > Actually, I don't think it was lack of code that stalled the discussion, > but an embarassment of options on how to solve the "XDTD problem". that's not the conclusion i came to ... which is not to say my conclusion is right :) > > > > The major issue I see is that Apache's configuration is extensible, but > > > DTDs are not (at least, as far as I understand them). So, some kind of > > > XDTD (to coin an acronym) is needed. I believe such things do exist, but > > > I don't know much about them. However, the fact that they are plural > > > worries me :-) > > > > > > > i'd start bottom up and grow this organically. further > > i propose considering the configuration approach used > > by tomcat as a starting point as 1) it is simple and > > 2) it is based on xml and java and as such should be > > impervious of many platform specific concerns. > > Well, that's fine and dandy, but... > > > now, by saying it is simple i am not implying that > > it will solve world hunger ... quite the opposite. > > if we can get subsystem (eg tomcat servlet container) > > configurations to become real and portable then > > hosting system configuration concerns becomes at > > some level just a matter of interacting and instrumenting > > the various subsystems configuration api. > > ...I think that until you think about how to integrate subsystems you > haven't addressed any problems that don't fall into the realm of the > bleedin' obvious(tm). To take a really trivial Apache example, some > modules have some configuration that can appear within <VirtualHost ...> > sections, and some that can't. The XDTD should define this, rigorously. > Somehow. Ideally in a way that everyone thinks is good and is > standardised. > this is why i'm suggesting that we consider what it would take to manage a collection of component/subsystem/etc configurations as deemed appropriate by the component vs trying to configuration everything nut and bolt a hosting system is and/or may be comprised of in a manner deemed appropriate by the hosting system. the hosting system need not know or be exposed to the component details but instead provided the bare minimum needed to establish the relationship and delegate the work to the component. the work is in definining the interface amongst the container and the component. - james From jose88@example.org Mon Oct 11 20:41:14 1999 Return-Path: <jose88@example.org> Mailing-List: contact jose88@example.org; run by ezmlm Delivered-To: mailing list jose88@example.org Received: (qmail 22195 invoked from network); 11 Oct 1999 20:41:14 -0000 Received: from eastwood.aldigital.algroup.co.uk (83.161.120.155) by apache.org with SMTP; 11 Oct 1999 20:41:14 -0000 Received: from freeby.ben.algroup.co.uk (freeby.ben.algroup.co.uk [83.161.120.155]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id UAA09032; Mon, 11 Oct 1999 20:39:19 GMT Received: from algroup.co.uk (naughty.ben.algroup.co.uk [83.161.120.155]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id VAA27803; Mon, 11 Oct 1999 21:39:43 +0100 Message-ID: <jose88@example.org> Date: Mon, 11 Oct 1999 21:39:17 +0100 From: Ben Laurie <jose88@example.org> Organization: A.L. Group plc X-Mailer: Mozilla 4.7 [en] (WinNT; I) MIME-Version: 1.0 To: jose88@example.org CC: jose88@example.org Subject: Re: XML configuration revisited References: <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit James Todd wrote: > > ...I think that until you think about how to integrate subsystems you > > haven't addressed any problems that don't fall into the realm of the > > bleedin' obvious(tm). To take a really trivial Apache example, some > > modules have some configuration that can appear within <VirtualHost ...> > > sections, and some that can't. The XDTD should define this, rigorously. > > Somehow. Ideally in a way that everyone thinks is good and is > > standardised. > > > > this is why i'm suggesting that we consider what it > would take to manage a collection of component/subsystem/etc > configurations as deemed appropriate by the component > vs trying to configuration everything nut and bolt a > hosting system is and/or may be comprised of in a manner > deemed appropriate by the hosting system. > > the hosting system need not know or be exposed to the > component details but instead provided the bare minimum > needed to establish the relationship and delegate the > work to the component. the work is in definining the > interface amongst the container and the component. I'm finding that a little difficult to parse, but assuming I've understood you, I think I agree. However, I suspect that all you've done is restated the problem without getting us any closer to a solution. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi From jose88@example.org Mon Oct 11 20:41:41 1999 Return-Path: <jose88@example.org> Mailing-List: contact jose88@example.org; run by ezmlm Delivered-To: mailing list jose88@example.org Received: (qmail 23194 invoked from network); 11 Oct 1999 20:41:41 -0000 Received: from pop.systemy.it (83.161.120.155) by apache.org with SMTP; 11 Oct 1999 20:41:41 -0000 Received: from apache.org (pv5-pri.systemy.it [83.161.120.155]) by pop.systemy.it (8.8.8/8.8.3) with ESMTP id WAA13098; Mon, 11 Oct 1999 22:41:13 +0200 Message-ID: <jose88@example.org> Date: Mon, 11 Oct 1999 22:43:33 +0200 From: Stefano Mazzocchi <jose88@example.org> Organization: Apache Software Foundation X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: it,en MIME-Version: 1.0 To: jose88@example.org CC: jose88@example.org Subject: Re: XML configuration revisited References: <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ben Laurie wrote: > Actually, I don't think it was lack of code that stalled the discussion, > but an embarassment of options on how to solve the "XDTD problem". [...] > ...I think that until you think about how to integrate subsystems you > haven't addressed any problems that don't fall into the realm of the > bleedin' obvious(tm). To take a really trivial Apache example, some > modules have some configuration that can appear within <VirtualHost ...> > sections, and some that can't. The XDTD should define this, rigorously. > Somehow. Ideally in a way that everyone thinks is good and is > standardised. There are solutions to this problem but require a significant perpective change. 1) Do not validate. Let XML be well-formed and let the server understand if the format has a valid meaning. This is what currently happens with both Apache and java.apache projects. Wellformness, is these cases, is ASCII compliance (which we take for granted!) This solution allows you to remove the "contract" inside the DTD and replace it with documentation. Exactly like it's done today. True, part of the XML idea is lost. 2) Use namespaces. Let every module define it's namespace and it's own DTD. Currently the XML spec doesn't allow this, but the XSchema WG is specifically working to integrate what you defined as "XDTD", thus the ability to have different pars of the document being validated by different DTDs. The IBM XML4J parser (don't know about the C++ version) is currently supporting XSchema for validation, but I don't know its status. 3) Use pseudo-RDF. Create a meta-configuration language which is what a group of four of us (Daniel Lopez Ridruejo, Eric Proud'Hommaux, Pierpaolo Fumagalli and myself) have been jose88@example.org. This XML should have information _about_ configurations and drive human interaction programs (either GUI, command line or web based) to create a valid configuration file. But this could very well be a superset of the configuration XSchema. To conclude: using a single DTD for configuration is too complicated, therefore it's not useful unless machine created. Since configurations should be human editable, we need a way to separate different validation rules on their contexts. Placing validation rule definition to the project/module developers, and allowing those validation rules to be _merged_ without influencing the "container" DTD. I believe the XSchema spec is what we lack to provide such a configuration framework. Thing that would also allow configuration tools to work on every ASF project based on it. Hope this is useful. -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. <jose88@example.org> Friedrich Nietzsche --------------------------------------------------------------------- From jose88@example.org Mon Oct 11 21:14:14 1999 Return-Path: <jose88@example.org> Mailing-List: contact jose88@example.org; run by ezmlm Delivered-To: mailing list jose88@example.org Received: (qmail 23825 invoked from network); 11 Oct 1999 21:14:14 -0000 Received: from eastwood.aldigital.algroup.co.uk (83.161.120.155) by apache.org with SMTP; 11 Oct 1999 21:14:14 -0000 Received: from freeby.ben.algroup.co.uk (freeby.ben.algroup.co.uk [83.161.120.155]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id VAA10497; Mon, 11 Oct 1999 21:12:57 GMT Received: from algroup.co.uk (naughty.ben.algroup.co.uk [83.161.120.155]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id WAA28053; Mon, 11 Oct 1999 22:13:22 +0100 Message-ID: <jose88@example.org> Date: Mon, 11 Oct 1999 22:12:56 +0100 From: Ben Laurie <jose88@example.org> Organization: A.L. Group plc X-Mailer: Mozilla 4.7 [en] (WinNT; I) MIME-Version: 1.0 To: jose88@example.org CC: jose88@example.org Subject: Re: XML configuration revisited References: <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stefano Mazzocchi wrote: > > Ben Laurie wrote: > > > Actually, I don't think it was lack of code that stalled the discussion, > > but an embarassment of options on how to solve the "XDTD problem". > > [...] > > > ...I think that until you think about how to integrate subsystems you > > haven't addressed any problems that don't fall into the realm of the > > bleedin' obvious(tm). To take a really trivial Apache example, some > > modules have some configuration that can appear within <VirtualHost ...> > > sections, and some that can't. The XDTD should define this, rigorously. > > Somehow. Ideally in a way that everyone thinks is good and is > > standardised. > > There are solutions to this problem but require a significant perpective > change. > > 1) Do not validate. > > Let XML be well-formed and let the server understand if the format has a > valid meaning. This is what currently happens with both Apache and > java.apache projects. Wellformness, is these cases, is ASCII compliance > (which we take for granted!) > > This solution allows you to remove the "contract" inside the DTD and > replace it with documentation. Exactly like it's done today. True, part > of the XML idea is lost. No, Apache config _is_ validated. > 2) Use namespaces. > > Let every module define it's namespace and it's own DTD. Currently the > XML spec doesn't allow this, but the XSchema WG is specifically working > to integrate what you defined as "XDTD", thus the ability to have > different pars of the document being validated by different DTDs. > > The IBM XML4J parser (don't know about the C++ version) is currently > supporting XSchema for validation, but I don't know its status. Well, that's cool, but I'm not sure I understand the "own DTD" aspect: we require a mix (that is, a module needs to be able to say "these tags are valid within that other modules tag-so-and-so"). > 3) Use pseudo-RDF. > > Create a meta-configuration language which is what a group of four of us > (Daniel Lopez Ridruejo, Eric Proud'Hommaux, Pierpaolo Fumagalli and > myself) have been jose88@example.org. > > This XML should have information _about_ configurations and drive human > interaction programs (either GUI, command line or web based) to create a > valid configuration file. Exactly. > But this could very well be a superset of the configuration XSchema. Pointer? > To conclude: using a single DTD for configuration is too complicated, > therefore it's not useful unless machine created. Not quite sure I see why this rules it out? > Since configurations should be human editable, we need a way to separate > different validation rules on their contexts. Placing validation rule > definition to the project/module developers, and allowing those > validation rules to be _merged_ without influencing the "container" DTD. Some validation is probably too complex to handle in "XDTD" but at present Apache doesn't detect those: it just fails to work. The majority of interesting cases are grammatical, IMO. > I believe the XSchema spec is what we lack to provide such a > configuration framework. Thing that would also allow configuration tools > to work on every ASF project based on it. That would be doublepluscool. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi From jose88@example.org Mon Oct 11 21:23:29 1999 Return-Path: <jose88@example.org> Mailing-List: contact jose88@example.org; run by ezmlm Delivered-To: mailing list jose88@example.org Received: (qmail 3844 invoked from network); 11 Oct 1999 21:23:29 -0000 Received: from mercury.sun.com (83.161.120.155) by apache.org with SMTP; 11 Oct 1999 21:23:29 -0000 Received: from engmail1.Eng.Sun.COM ([83.161.120.155]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA06112; Mon, 11 Oct 1999 14:23:07 -0700 (PDT) Received: from taller.eng.sun.com (taller.Eng.Sun.COM [83.161.120.155]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id OAA01998; Mon, 11 Oct 1999 14:23:06 -0700 (PDT) Received: from eng.sun.com by taller.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA20823; Mon, 11 Oct 1999 14:23:03 -0700 Message-ID: <jose88@example.org> Date: Mon, 11 Oct 1999 14:24:03 -0700 From: James Todd <jose88@example.org> Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: jose88@example.org CC: jose88@example.org Subject: Re: XML configuration revisited References: <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ben Laurie wrote: > > James Todd wrote: > > > ...I think that until you think about how to integrate subsystems you > > > haven't addressed any problems that don't fall into the realm of the > > > bleedin' obvious(tm). To take a really trivial Apache example, some > > > modules have some configuration that can appear within <VirtualHost ...> > > > sections, and some that can't. The XDTD should define this, rigorously. > > > Somehow. Ideally in a way that everyone thinks is good and is > > > standardised. > > > > > > > this is why i'm suggesting that we consider what it > > would take to manage a collection of component/subsystem/etc > > configurations as deemed appropriate by the component > > vs trying to configuration everything nut and bolt a > > hosting system is and/or may be comprised of in a manner > > deemed appropriate by the hosting system. > > > > the hosting system need not know or be exposed to the > > component details but instead provided the bare minimum > > needed to establish the relationship and delegate the > > work to the component. the work is in definining the > > interface amongst the container and the component. > > I'm finding that a little difficult to parse, but assuming I've > understood you, I think I agree. However, I suspect that all you've done > is restated the problem without getting us any closer to a solution. > [i'm about 1.5 days away from a 1-week 10th year wedding anniversary vacation so i will be the first to admit that it is quite likely that i am somewhat less then 100% in tune with this thread :) ] configuration issues have been around from day one and typically is an afterthought from a less then black box perspective. as such, i feel the adoption, usage and extension of software packages is limited. i believe aggregating software will necessarily have to open up and delegate a certain amount of configuration responsibilities to the comprised components. this approach is the very catalyst which launched the industrial age ... and the same needs to be done for software. some standards and agreed upon interfaces will evolve but i don't believe that hosting software need know or care about a large percentage of the inner workings of a component module and vice versa. to require such would severly impact adoption, extension, pluggability, scalability, etc on all fronts. further, i feel organically growing configurable and autonomous components from the ground up and with the explicit goal of doing one thing really well (eg servlet container) is actually quite doable. with some a perspective, i believe stitching these components together in new and interesting ways is also quite viable. hope this helps, - james From jose88@example.org Mon Oct 11 21:52:17 1999 Return-Path: <jose88@example.org> Mailing-List: contact jose88@example.org; run by ezmlm Delivered-To: mailing list jose88@example.org Received: (qmail 3603 invoked from network); 11 Oct 1999 21:52:17 -0000 Received: from ti34a24-0014.dialup.online.no (HELO tildeslash.com) (83.161.120.155) by apache.org with SMTP; 11 Oct 1999 21:52:17 -0000 Received: (from hauk@localhost) by tildeslash.com (8.9.3/8.9.3) id XAA13589; Mon, 11 Oct 1999 23:58:03 +0200 To: jose88@example.org Cc: jose88@example.org Subject: Re: XML configuration revisited References: <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> From: Jan-Henrik Haukeland <jose88@example.org> Date: 11 Oct 1999 23:58:03 +0200 In-Reply-To: Ben Laurie's message of "Mon, 11 Oct 1999 21:39:17 +0100" Message-ID: <jose88@example.org> Lines: 27 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "20 Minutes to Nikko" Ben Laurie <jose88@example.org> writes: > James Todd wrote: > > > > the hosting system need not know or be exposed to the > > component details but instead provided the bare minimum > > needed to establish the relationship and delegate the > > work to the component. the work is in definining the > > interface amongst the container and the component. > > I'm finding that a little difficult to parse, but assuming I've > understood you, I think I agree. However, I suspect that all you've done > is restated the problem without getting us any closer to a solution. On the contrary, at least James et.al. did a good architectural stab at getting at one solution (http://java.sun.com/people/gonzo/tomcat/ConfigService.jpg) I do feel that James is right (also) when he said that it was the lack of code that sort of damped down the discussion. It's only possible to discuss the "emperors new clothes" that far. BTW AFAI remember, the discussion went much farther than discussing DTD's which is (and to an extent should be) only a _minor_ thing in this problem domain. -- Jan-Henrik Haukeland From jose88@example.org Mon Oct 11 22:23:00 1999 Return-Path: <jose88@example.org> Mailing-List: contact jose88@example.org; run by ezmlm Delivered-To: mailing list jose88@example.org Received: (qmail 29032 invoked from network); 11 Oct 1999 22:23:00 -0000 Received: from homer.bus.miami.edu (jose88@example.org) by apache.org with SMTP; 11 Oct 1999 22:23:00 -0000 Received: by homer.bus.miami.edu (8.8.8/83.161.120.155/08Mar98-0513AM) id SAA0000026025; Mon, 11 Oct 1999 18:22:37 -0400 (EDT) Date: Mon, 11 Oct 1999 18:22:36 -0400 From: Troy Poppe <jose88@example.org> To: jose88@example.org Subject: Re: XML configuration revisited Message-ID: <jose88@example.org> References: <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <jose88@example.org>; from Jan-Henrik Haukeland on Mon, Oct 11, 1999 at 11:58:03PM +0200 On Mon, Oct 11, 1999 at 11:58:03PM +0200, Jan-Henrik Haukeland wrote: > Ben Laurie <jose88@example.org> writes: > > > James Todd wrote: > > > > > > the hosting system need not know or be exposed to the > > > component details but instead provided the bare minimum > > > needed to establish the relationship and delegate the > > > work to the component. the work is in definining the > > > interface amongst the container and the component. > > > > I'm finding that a little difficult to parse, but assuming I've > > understood you, I think I agree. However, I suspect that all you've done > > is restated the problem without getting us any closer to a solution. > > On the contrary, at least James et.al. did a good architectural stab > at getting at one solution > > (http://java.sun.com/people/gonzo/tomcat/ConfigService.jpg) > > I do feel that James is right (also) when he said that it was the lack > of code that sort of damped down the discussion. It's only possible to > discuss the "emperors new clothes" that far. BTW AFAI remember, the > discussion went much farther than discussing DTD's which is (and to an > extent should be) only a _minor_ thing in this problem domain. Actually, I was about to say the same thing (thanks Jan). We got to the point where we determined that we needed to know more about what we were looking at as far as scope in order to determine where to go next. (ie. look at the code drop and figure out how things are interally structured). Also, does anyone remember the colloraboration(horribly misspelled ;) ) tool discussion? Did we ever decide on any particular tool? Together/J was mentioned, as was VThought. (I remember hearing that we probably had a better chance with Together/J because of the Java aspect). Anyone adverse to starting that discussion again? Perhaps a [VOTE] thread on this? - Troy From jose88@example.org Mon Oct 11 22:54:33 1999 Return-Path: <jose88@example.org> Mailing-List: contact jose88@example.org; run by ezmlm Delivered-To: mailing list jose88@example.org Received: (qmail 19103 invoked from network); 11 Oct 1999 22:54:33 -0000 Received: from ha1.rdc1.ct.home.com (HELO mail.rdc1.ct.home.com) (jose88@example.org) by apache.org with SMTP; 11 Oct 1999 22:54:33 -0000 Received: from littlefoot ([83.161.120.155]) by mail.rdc1.ct.home.com (InterMail v83.161.120.155 201-229-111-110) with SMTP id <19991012003634.MLIX3646.mail.rdc1.ct.home.com@littlefoot> for <jose88@example.org>; Mon, 11 Oct 1999 17:36:34 -0700 Message-ID: <003b01bf143b$8d9a7840$0200a8c0@littlefoot> From: "Scott Tavares" <jose88@example.org> To: <jose88@example.org> References: <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> Subject: Re: XML configuration revisited Date: Mon, 11 Oct 1999 18:54:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Don't forget Argo/UML http://www.ics.uci.edu/pub/arch/uml/ & http://www.ics.uci.edu/pub/arch/uml/v07/docs/codeorg.html ----- Original Message ----- From: Troy Poppe <jose88@example.org> To: <jose88@example.org> Sent: Monday, October 11, 1999 6:22 PM Subject: Re: XML configuration revisited > On Mon, Oct 11, 1999 at 11:58:03PM +0200, Jan-Henrik Haukeland wrote: > > Ben Laurie <jose88@example.org> writes: > > > > > James Todd wrote: > > > > > > > > the hosting system need not know or be exposed to the > > > > component details but instead provided the bare minimum > > > > needed to establish the relationship and delegate the > > > > work to the component. the work is in definining the > > > > interface amongst the container and the component. > > > > > > I'm finding that a little difficult to parse, but assuming I've > > > understood you, I think I agree. However, I suspect that all you've done > > > is restated the problem without getting us any closer to a solution. > > > > On the contrary, at least James et.al. did a good architectural stab > > at getting at one solution > > > > (http://java.sun.com/people/gonzo/tomcat/ConfigService.jpg) > > > > I do feel that James is right (also) when he said that it was the lack > > of code that sort of damped down the discussion. It's only possible to > > discuss the "emperors new clothes" that far. BTW AFAI remember, the > > discussion went much farther than discussing DTD's which is (and to an > > extent should be) only a _minor_ thing in this problem domain. > > Actually, I was about to say the same thing (thanks Jan). We got to > the point where we determined that we needed to know more about what > we were looking at as far as scope in order to determine where to go > next. (ie. look at the code drop and figure out how things are interally > structured). > > Also, does anyone remember the colloraboration(horribly misspelled ;) ) > tool discussion? Did we ever decide on any particular tool? Together/J > was mentioned, as was VThought. (I remember hearing that we probably > had a better chance with Together/J because of the Java aspect). Anyone > adverse to starting that discussion again? Perhaps a [VOTE] thread > on this? > > - Troy > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: jose88@example.org > For additional commands, e-mail: jose88@example.org > From jose88@example.org Mon Oct 11 23:25:50 1999 Return-Path: <jose88@example.org> Mailing-List: contact jose88@example.org; run by ezmlm Delivered-To: mailing list jose88@example.org Received: (qmail 15388 invoked from network); 11 Oct 1999 23:25:50 -0000 Received: from dnai-216-15-97-206.cust.dnai.com (HELO kali.betaversion.org) (83.161.120.155) by apache.org with SMTP; 11 Oct 1999 23:25:50 -0000 Received: from apache.org(s2.almaden.ibm.com[83.161.120.155]) (1715 bytes) by kali.betaversion.org via smail with P:esmtp/R:internet/T:smtp (sender: <jose88@example.org>) id <jose88@example.org> for <jose88@example.org>; Mon, 11 Oct 1999 16:25:16 -0700 (PDT) (Smail-83.161.120.155 1999-Mar-31 #3 built 1999-Sep-21) Message-ID: <jose88@example.org> Date: Mon, 11 Oct 1999 16:23:01 -0700 From: Pierpaolo Fumagalli <jose88@example.org> Organization: Apache Software Foundation Member X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: jose88@example.org CC: jose88@example.org Subject: Re: XML configuration revisited References: <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ben Laurie wrote: > > No, Apache config _is_ validated. > > [...] > > Well, that's cool, but I'm not sure I understand the "own DTD" aspect: > we require a mix (that is, a module needs to be able to say "these tags > are valid within that other modules tag-so-and-so"). > Sorry, but I think these two are contraddicting... How can you have a DTD if you don't know the elements that are in your XML file? Either you generate a DTD depending on your Apache configuration (so for whatever module gets compiled in or loaded as DSO) or you cannot properly "validate" (in the strict term of validation against a DTD) the source. Pier -- Pierpaolo Fumagalli - IBM Center for Java Technologies <mailto:jose88@example.org> <mailto:jose88@example.org> ====================================================== IBM Notes ID: Pierpaolo Fumagalli/Cupertino/IBM@IBMUS Telephone: 205-350-3838 - IBM Tieline #: 240-5838 From jose88@example.org Tue Oct 12 00:09:16 1999 Return-Path: <jose88@example.org> Mailing-List: contact jose88@example.org; run by ezmlm Delivered-To: mailing list jose88@example.org Received: (qmail 17900 invoked from network); 12 Oct 1999 00:09:16 -0000 Received: from mercury.sun.com (83.161.120.155) by apache.org with SMTP; 12 Oct 1999 00:09:16 -0000 Received: from engmail2.Eng.Sun.COM ([83.161.120.155]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA11478 for <jose88@example.org>; Mon, 11 Oct 1999 17:08:54 -0700 (PDT) Received: from taller.eng.sun.com (taller.Eng.Sun.COM [83.161.120.155]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id RAA06020 for <jose88@example.org>; Mon, 11 Oct 1999 17:08:54 -0700 (PDT) Received: from eng.sun.com by taller.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA04463; Mon, 11 Oct 1999 17:08:52 -0700 Message-ID: <jose88@example.org> Date: Mon, 11 Oct 1999 17:09:52 -0700 From: James Todd <jose88@example.org> Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: jose88@example.org Subject: Re: XML configuration revisited References: <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit agreed. having an agreed upon dtd before anything else can be done is very short sighted. i've seen quite a few projects get in very tight loops on that very topic. by going xml, validated or not, we at least have a config format which should be easy to change later on when we know we have to ... since we don't have to write the parser. we need an xml dtd to start the juices flowing, hence my submition of tomcat server.xml (the tags have changed a bit since we've last spoken but the goal is the same) as some that works at one level and should be easy enough to shape into whatever we choose moving forward. bigger picture, i still believe we should start small and grow this the smallish and understandable components perspective vs the top-down container perspective. it will have to be that way for any fast moving and open (ie easily embraces new technologies) architecture ... to do othewise would be a never ending spiral. i'm still game and have not changed my opinions on this matter a bit ... but open to ideas. hope this helps, - james Jan-Henrik Haukeland wrote: > > Ben Laurie <jose88@example.org> writes: > > > James Todd wrote: > > > > > > the hosting system need not know or be exposed to the > > > component details but instead provided the bare minimum > > > needed to establish the relationship and delegate the > > > work to the component. the work is in definining the > > > interface amongst the container and the component. > > > > I'm finding that a little difficult to parse, but assuming I've > > understood you, I think I agree. However, I suspect that all you've done > > is restated the problem without getting us any closer to a solution. > > On the contrary, at least James et.al. did a good architectural stab > at getting at one solution > > (http://java.sun.com/people/gonzo/tomcat/ConfigService.jpg) > > I do feel that James is right (also) when he said that it was the lack > of code that sort of damped down the discussion. It's only possible to > discuss the "emperors new clothes" that far. BTW AFAI remember, the > discussion went much farther than discussing DTD's which is (and to an > extent should be) only a _minor_ thing in this problem domain. > > -- > Jan-Henrik Haukeland > > --------------------------------------------------------------------- > To unsubscribe, e-mail: jose88@example.org > For additional commands, e-mail: jose88@example.org From jose88@example.org Tue Oct 12 00:13:39 1999 Return-Path: <jose88@example.org> Mailing-List: contact jose88@example.org; run by ezmlm Delivered-To: mailing list jose88@example.org Received: (qmail 21830 invoked from network); 12 Oct 1999 00:13:39 -0000 Received: from mercury.sun.com (83.161.120.155) by apache.org with SMTP; 12 Oct 1999 00:13:39 -0000 Received: from engmail4.Eng.Sun.COM ([83.161.120.155]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA12766 for <jose88@example.org>; Mon, 11 Oct 1999 17:13:16 -0700 (PDT) Received: from taller.eng.sun.com (taller.Eng.Sun.COM [83.161.120.155]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id RAA21188 for <jose88@example.org>; Mon, 11 Oct 1999 17:12:46 -0700 (PDT) Received: from eng.sun.com by taller.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA04772; Mon, 11 Oct 1999 17:12:44 -0700 Message-ID: <jose88@example.org> Date: Mon, 11 Oct 1999 17:13:44 -0700 From: James Todd <jose88@example.org> Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: jose88@example.org Subject: Re: XML configuration revisited References: <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Troy Poppe wrote: > > > Also, does anyone remember the colloraboration(horribly misspelled ;) ) > tool discussion? Did we ever decide on any particular tool? Together/J > was mentioned, as was VThought. (I remember hearing that we probably > had a better chance with Together/J because of the Java aspect). Anyone > adverse to starting that discussion again? Perhaps a [VOTE] thread > on this? > > - Troy > !sweet! let's rock. tool wise i believe it was togetherJ and argo. i've used togetherJ and can live with it but i wouldn't be adversed to trying something else out. i love visualThoughts drawing capabilities but i can't see how it will help much more then a box'o crayons with respect to object modeling, java design, etc when compared to togetherJ. now that the code is available, or soon will be, let's move this discussion to the next level and i'm still on board to explain why things where done the way they where in addition to the more forward thinking discussions such as where we think we should be with regards to component software configuration, infrastructure, dependecies, and the like. - james [1 day out from taking a week off] todd From jose88@example.org Tue Oct 12 02:41:26 1999 Return-Path: <jose88@example.org> Mailing-List: contact jose88@example.org; run by ezmlm Delivered-To: mailing list jose88@example.org Received: (qmail 21179 invoked from network); 12 Oct 1999 02:41:26 -0000 Received: from unknown (HELO valhalla.echidna.net) (83.161.120.155) by apache.org with SMTP; 12 Oct 1999 02:41:25 -0000 Received: from loki.echidna.net by valhalla.echidna.net (NX5.67e/NX3.0M.003) id AA29029; Mon, 11 Oct 99 18:55:16 -0700 Message-Id: <jose88@example.org> Reply-To: "Thor Heinrichs-Wolpert" <jose88@example.org> From: "Thor Heinrichs-Wolpert" <jose88@example.org> To: <jose88@example.org> Cc: <jose88@example.org> References: <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> <jose88@example.org> Subject: Re: XML configuration revisited Date: Mon, 11 Oct 1999 19:38:43 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 James: I thought this might be somewhat appropriate for you to take next week. My father past it along to me, and I thought it would be fitting, since you are in an Apache project after all *g* Thor HW ------------ Apache Blessing Now you will feel no rain for each of you will be shelter for each other Now you will feel no cold for each of you will be warmth for each other Now there is no more loneliness for you for each of you will be companion for the other Now you are two bodies but there is only one life before you Go now to your dwelling to enter into the days of togetherness May your days be good and long upon this earth From jose88@example.org Tue Oct 12 02:43:23 1999 Return-Path: <jose88@example.org> Mailing-List: contact jose88@example.org; run by ezmlm Delivered-To: mailing list jose88@example.org Received: (qmail 22546 invoked from network); 12 Oct 1999 02:43:23 -0000 Received: from unknown (HELO valhalla.echidna.net) (83.161.120.155) by apache.org with SMTP; 12 Oct 1999 02:43:23 -0000 Received: from loki.echidna.net by valhalla.echidna.net (NX5.67e/NX3.0M.003) id AA29052; Mon, 11 Oct 99 18:57:17 -0700 Message-Id: <jose88@example.org> Reply-To: "Thor Heinrichs-Wolpert" <jose88@example.org> From: "Thor Heinrichs-Wolpert" <jose88@example.org> To: <jose88@example.org>, <jose88@example.org> Subject: James: Apache Blessing Date: Mon, 11 Oct 1999 19:40:44 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Sorry, I think I hit send to early *g* James: I thought this might be somewhat appropriate for you to take next week. My father past it along to me, and I thought it would be fitting, since you are in an Apache project after all *g* Thor HW ------------ Apache Blessing Now you will feel no rain for each of you will be shelter for each other Now you will feel no cold for each of you will be warmth for each other Now there is no more loneliness for you for each of you will be companion for the other Now
{'source': 'Apache Software Foundation Public Mail Archives'}