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 87001 invoked from network); 1 Feb 2000 23:51:15 -0000 Received: from adsl-63-198-47-229.dsl.snfc21.pacbell.net (HELO costin.dnt.ro) (63.198.47.229) by 63.211.145.10 with SMTP; 1 Feb 2000 23:51:15 -0000 Received: from eng.sun.com (costin [63.198.47.229]) by costin.dnt.ro (8.9.3+Sun/8.9.1) with ESMTP id PAA26407; Tue, 1 Feb 2000 15:51:10 -0800 (PST) Sender: costin@costin.dnt.ro Message-ID: <389771C8.CC9B2C99@eng.sun.com> Date: Tue, 01 Feb 2000 15:52:40 -0800 From: Costin Manolache X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: tomcat-dev@jakarta.apache.org CC: new-httpd@apache.org, JServ Development Subject: Re: [Proposal] "Relayed" Apache API Project References: <389764CA.27ABD0DF@algroup.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > My proposal is to separate the discussion it 2 or 3: > > > > 1. What API do we want to expose to remote engines ( for example > > sub_request but not pool ). > > > > 2. What wire protocol should we use ( message format and encoding, CDR or > > XDR or AJP or something else ?) > > > > 2 or 3. What communication mechanism - TCP is a clear one, but we want to > > support unix pipes or shared memory or doors. > > > > It is not very difficult to make it modular - and probably the best way to > > start would be to re-use some existing code and then invent new protocols. > > > > I think the API is the most difficult and important part, it's a big > > difference between local calls and IPC ( we must expose non-trivial > > calls, etc). > > But isn't that the huge attraction of CORBA? I define the API and the > wire is handled for me? Also, I get cross-language compatibility, as > well as cross-platform. Yes, we should use something out of CORBA - at least the ideea of defining the API independent of wire protocol. Full Corba may be a bad ideea - it is big, complex, will have problems with Apache thread model and I don't know any Apache-license-compatible ORBs. But using some IIOP _ideas_ is not bad at all - the CDR encoding is not much worse than AJP, and the wire protocol is not much worse than AJP. If we use CDR and the wire protocol it will not be very hard to make our protocol interoperable with a real ORB ( and save a lot of programming on the other side ), and it's good to use some standards instead of defining new one.( assuming CDR and basic GIOP are not too heavy - I really don't think this is the case). Costin