Re: mod_custom_log exits too late?
[a little birdie said folks were quoting me ;) hi!] On 16 Sep 2002, Brian Pane wrote: Linux kernel modules are a special case due to some characteristics that don't apply to Apache: * Most Linux kernel modules are available in source form most are available in source form simply because source is the only form in which compatibility is remotely guaranteed. and also because the l-k folks (rightly) refuse to support any bug reports from folks with binary modules linked into their kernel. note that linux modules are not covered by GPL -- it *is* possible to release a binary only module, and some vendors attempt it. but the typical reaction by linux users is to avoid the hardware which requires binary only modules. * All modules are well-integrated with the kernel's build system not even close. try building a kernel with pcmcia, i2c, lm_sensors, freeswan, ... it's just as painful as trying to build apache with anything more complicated than cp mod_foobar.c src/modules/extra. * Most Linux installations have the necessary tools for recompilation from which it follows that most apache installations have the necessary compilation tools... (do i have to go dig out the old netcraft apache/os distribution statistics? :) Those things aren't generally true for Apache modules. If you're running on a Solaris box with no compiler, with binary-only modules from third party vendors, and the next release of Apache 2.0 increments the MMN major, then you're stuck. yeah well if you don't have the compiler then you can't even compile the next apache-2.0 :) stop providing binary downloads at apache.org and this problem goes away as well. :) even solaris boxes come with gcc as of 8/9 don't they? A better example is the Linux system call interface: that almost never breaks backward compatibility, and that's what allows users to upgrade their kernels to a new maintenance release without fear of breaking every app they depend on. the linux system call interface is *not* an analogous interface to the apache module API. system calls, for example, cross a protection domain which is largely enforced by the CPU hardware. (but which requires special tests in every system call to ensure hax0rs aren't attacking ring 0). this userlevel/kernel separation is a very fundamental layering... which apache does not have -- and which i think apache would be better off having... but it's a fundamental paradigm shift. if you wanted an analogous API for apache then you'd need to use IPC or RPC to provide inter-module protection using multiple processes. this is something i've mentioned before as well -- it eliminates linkage issues; segfault issues; ... to design such an IPC/RPC you'd have to put as much effort into the fundamental design of the API as goes into system call design. that's not to say system calls never change -- you need only look through the linux system call table to see several new replacements for old system calls. glibc tends to provide a layer of indirection so that old code continues to work as the syscalls change. glibc even provides parameter/structure marshalling so that changes can be made in kernel-side structures without affecting user programs that depend on structure layouts. (this is the case in essentially every unix, linux is just the example at hand. for a solaris example look at the crappy solaris 2.5 TCP over STREAMs implementation... prior to 2.5 and after 2.5 TCP syscalls exist, but in 2.5 they're library routines which make STREAMS syscalls.) trust me: you're doing a huge disservice to the advancement of the state of the art by locking yourselves into a binary compatibility mentality. i can't see any benefit to binary compatibility except in allowing corporate vendors to hide their intellectual property -- and not share it with the community at large (an effort which we should all be aware is fundamentally worthless -- since reverse engineering can and does happen every day, and is even a personal right in reasonable countries in this world). and as a (retired) apache contributor i find that not only weak, but in fact a non-argument. there is no technology worth protecting like this. if the vendor wants to benefit from all this free IP they're getting from us, then they should at least give a minor amount of effort back. apache isn't GPL -- if vendors want binary crap, then they can make a real C binary library, and provide an apache layer similar to the libc layer i described above for syscalls. 6 years ago a vendor wanted WiReD to link a proprietary binary auditing module into their httpd, and i refused. i refused until the vendor gave me a C library and a simple wrapper i could use to rebuild my server with. the vendor agreed, and we all were happy in the end. -dean
Re: mod_custom_log exits too late?
On Mon, Sep 16, 2002 at 09:46:47AM -0700, Brian Pane wrote: I disagree entirely. There's no need to let the API keep changing continuously, especially not for the sake of correctness. All of our competitors provide API stability. And as a result, people who develop modules for, say, IIS or IPlanet don't need to worry about their code breaking with every maintenance release. I think you're missing a huge point here. You *cannot* tell IIS or iPlanet that their APIs suck. You probably can't even fix problems in their servers. You're stuck. You *can* tell us that our APIs suck and provide patches on ways to improve - especially for 2.0. I think that our APIs will stabilize, but ~6 months into GA, we're not there yet. As I've pointed out earlier, it took well over a year for 1.3 to reach this state. I don't see us being faster. -- justin
Re: mod_custom_log exits too late?
On Mon, 2002-09-16 at 23:32, Justin Erenkrantz wrote: On Mon, Sep 16, 2002 at 09:46:47AM -0700, Brian Pane wrote: I disagree entirely. There's no need to let the API keep changing continuously, especially not for the sake of correctness. All of our competitors provide API stability. And as a result, people who develop modules for, say, IIS or IPlanet don't need to worry about their code breaking with every maintenance release. I think you're missing a huge point here. You *cannot* tell IIS or iPlanet that their APIs suck. Of course you can. And if you're a big enough customer, your server vendor will take your comments seriously enough to improve APIs in the next major release. What a responsible vendor will not do, however, is break all their other customers' systems in the next maintenance release just because one customer didn't like the function signatures. You probably can't even fix problems in their servers. You're stuck. You *can* tell us that our APIs suck and provide patches on ways to improve - especially for 2.0. Sure. And we have an obligation to users and third party developers to take constructive input and work it in to future releases in a manner that won't break people's systems. Brian
Re: mod_custom_log exits too late?
On 17 Sep 2002, Brian Pane wrote: On Mon, 2002-09-16 at 23:32, Justin Erenkrantz wrote: On Mon, Sep 16, 2002 at 09:46:47AM -0700, Brian Pane wrote: I disagree entirely. There's no need to let the API keep changing continuously, especially not for the sake of correctness. All of our competitors provide API stability. And as a result, people who develop modules for, say, IIS or IPlanet don't need to worry about their code breaking with every maintenance release. I think you're missing a huge point here. You *cannot* tell IIS or iPlanet that their APIs suck. Of course you can. And if you're a big enough customer, your server vendor will take your comments seriously enough to improve APIs in the next major release. What a responsible vendor will not do, however, is break all their other customers' systems in the next maintenance release just because one customer didn't like the function signatures. You probably can't even fix problems in their servers. You're stuck. You *can* tell us that our APIs suck and provide patches on ways to improve - especially for 2.0. Sure. And we have an obligation to users and third party developers to take constructive input and work it in to future releases in a manner that won't break people's systems. I don't think we are going to end up agreeing. I also don't think it matters. The reality is that you can't get to binary compat without doing 1 of two things. 1) Wait until the API is ready. 2) Litter the API with multiple functions that all do the same thing in slightly different ways. #2 is bogus, and all it does is to make the API harder to understand. If you can somehow manage to acheive binary compat without doing either of these, then cool. Otherwise, I would much rather see us choose option #1, becuause it is less detrimental in the long run. The example that has been given so far, is the ap_filter_*_register functions, which had a function pointer added. The suggestion was that this could have been done by adding another function. Yes, it could have. But, you wouldn't be able to get rid of those functions until 3.0. As proof, we had functions from 1.2 that weren't removed until the 2.0 release. Sorry, but API pollution doesn't excite me. Between API pollution and breaking binary compat, I choose the latter. Commercial companies can't do this, because users don't have the source. Our users do, and we can do this. If a commercial company wants to modify Apache to provide binary backwards compat, they can do that, and as long as they remain within a single major version, the work shouldn't even be that hard. The other option, is for us to create an ap_compat.h header again. This would provide us with a level of source compat. I don't know why we haven't been keeping that file up to date. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
