Return-Path: Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 3595 invoked from network); 4 Aug 1999 19:38:36 -0000 Received: from mercury.sun.com (192.9.25.1) by apache.org with SMTP; 4 Aug 1999 19:38:36 -0000 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA02533 for ; Wed, 4 Aug 1999 12:38:35 -0700 (PDT) Received: from taller.eng.sun.com (taller.Eng.Sun.COM [129.144.250.34]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id MAA15739 for ; Wed, 4 Aug 1999 12:38:33 -0700 (PDT) Received: from eng.sun.com by taller.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA12892; Wed, 4 Aug 1999 12:37:44 -0700 Message-ID: <37A89714.32217560@eng.sun.com> Date: Wed, 04 Aug 1999 12:40:04 -0700 From: James Todd Organization: Sun Microsystems X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: tomcat-dev@jakarta.apache.org Subject: Re: config diag, etc References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit costin@dnt.ro wrote: > > > Ok clarification, again. > > > > We're constructing our own API for this configuration service, something > > that could be implemented in ANY language, on any platform, etc. > > Ok, but besides the fact that it will work in ANY language, on ANY > platform and support ALL existing protocols, I haven't heard anything > about the API itself. hmmm ... i consider this a bit extreme. i know that i have personally floated ideas for every single item you detailed below. i do plan on fleshing these out a bit more ... but to say that this hasn't been discussed is not the same picture i have. i'm ready to drill down now that i believe the dust has settled a bit on some core dependencies, and i'll repeat: http/s - cgi compliant service - xml formatted static data as a bare minimum. with the above statment firmly in mind, clients can interact with the config service in an "active" manner (translation: the client will get/post requests to the config service as it deems appropriate) or "passive" (translation: the client can publish a hook with which the config service can actively communicate with. > > > > 4. What data structure/model we want to use. That seems to be clear in > > > James document, if everyone agree we can clear this item. > > > > What exactly are you saying here? I don't quite understand what you mean > > by data structure/model. > > DTD. well, i believe the discussion doc to date discusses more then just dtd semantics although i will admit that that section is the most complete give i had an implemenation with which to reverse engineer. > > Costin > > --------------------------------------------------------------------- > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org