Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 29474 invoked by uid 6000); 27 Mar 1999 00:15:28 -0000 Received: (qmail 29465 invoked from network); 27 Mar 1999 00:15:27 -0000 Received: from unknown (HELO urizen.livesoftware.com) (209.125.2.254) by taz.hyperreal.org with SMTP; 27 Mar 1999 00:15:27 -0000 Received: (qmail 1469 invoked by uid 10003); 26 Mar 1999 01:01:45 -0000 From: "Thomas Reilly" To: new-httpd@apache.org Subject: Re: am I dreaming? References: <9903251518.aa05148@paris.ics.uci.edu> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: 25 Mar 1999 18:01:45 -0700 In-Reply-To: "Roy T. Fielding"'s message of "Thu, 25 Mar 1999 15:18:29 -0800" Message-ID: Lines: 67 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org "Roy T. Fielding" writes: > The ONLY way to provide binary compatibility across changes to the core > data structures is to prevent access to those structures and place an > intermediate translation module between the two. In other words, > mod_cgi, mod_perl, mod_php, mod_fastcgi, ... Such a layer does us no good. Let me clarify my situation. Our product is a servlet engine, in order for servlets to be executed the request is captured by our module and sent to our servlet engine via a socket based protocol. We provide the source for this module but our users (particularly the windows ones) love us to provide precompiled DSO's. Sure compiling the DSO with apxs is a one liner but a lot of systems don't have perl and precompiled DSOs allow us to to have servlets run on Apache just by installing our product and restarting apache. A big win for the non-hacker crowd. When I first posted I was under the impression that these breaks in binary compatibility could be avoided and were just oversights on the part of the developers who understandably don't care too much about binary compatibility. However its since become clear to me that normal healthy work on the server will break DSO compatability because there is no clean separation from the Apache core and the module architecture. Until DSOs came about there was no need for such a separation. Our module goes out of its way to not depend on Apache core. We do our own sockets calls and we don't make use of any preprocessor symbols (except the STANDARD_STUFF in module which is causing all our problems). Its understandable that Apache rejects our 1.3.4 module because it might have made use of the METHODS and M_INVALID definitions. I'm not sure how to deal with this. There seems to be two options: 1) Add a new module architecture cleanly abstracted from Apache core meant for use by DSOs 2) Make the current module architecture cleanly abstracted from Apache core Number 2 is obviously more appealing but may not be possible depending on how many core apache features the important modules need. I think such a clean change would be healthy for Apache and should maybe be considered for a pre 2.0 change. Is 1.3 the end of the 1.x line or is 1.4 a possibility? I think its pretty clear that my dreams won't be fulfilled in the 1.3 cycle. In response to the comparison to linux modules I don't think that is a fair one. The beauty of DSOs is that you can add functionality to an existing Apache server without rebuilding anything. Linux modules are primarily to combat the problem of the kernel size limitation. Anyways I don't think you can distribute a proprietary linux kernel module, I imagine these fall under the derivative works category and must be GPL'd. I apologize for the obscene length of this post. -- Tom Reilly Live Software, Inc http://www.livesoftware.com