From benjamin26@example.org Wed Apr 01 05:19:04 1998 Return-Path: <benjamin26@example.org> Delivered-To: benjamin26@example.org Received: (qmail 19875 invoked by uid 6000); 1 Apr 1998 05:19:03 -0000 Received: (qmail 19844 invoked from network); 1 Apr 1998 05:19:00 -0000 Received: from valis.worldgate.com (benjamin26@example.org) by taz.hyperreal.org with SMTP; 1 Apr 1998 05:19:00 -0000 Received: from localhost (marcs@localhost) by valis.worldgate.com (8.8.7/8.8.7) with SMTP id WAA14134 for <benjamin26@example.org>; Tue, 31 Mar 1998 22:18:58 -0700 (MST) Date: Tue, 31 Mar 1998 22:18:58 -0700 (MST) From: Marc Slemko <benjamin26@example.org> To: benjamin26@example.org Subject: Re: vetoing hide.h In-Reply-To: <benjamin26@example.org> Message-ID: <benjamin26@example.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: benjamin26@example.org Precedence: bulk Reply-To: benjamin26@example.org On Tue, 31 Mar 1998, Rasmus Lerdorf wrote: > in 1.3, then I am going to save myself the hassle and create my own > mapping in a header file, and voila, I am right back to something very > similar to hide.h. I don't mind doing this, but despite all the messages > that have passed by on this I don't see any compelling reason to do this > at this stage. [...] Having to do that is lame. > > However, I don't think you interpreted Roy's proposal correctly. The way > I read it, he would be providing the mapping for me, but in his version > the mapping is a hard mapping similar to my above example, but the other > way around. Something like: > > In my module I set EXPECTED_APACHE_API=19980202 to indicate that I want to > use old-style Apache symbols. Then in old_apache_api.h he would have: But that isn't what "EXPECTED_APACHE_API" is saying. It is supposedly more general than that; if it were just a prefix toggle then just call it that with a on or off. This is something claiming to be a general solution to API changes that is either not what it claims to be or causes the problems i described. I really don't see the need for it or how it does anything except create another mapping that is even worse. From benjamin26@example.org Wed Apr 01 08:18:13 1998 Return-Path: <benjamin26@example.org> Delivered-To: benjamin26@example.org Received: (qmail 857 invoked by uid 6000); 1 Apr 1998 08:18:11 -0000 Received: (qmail 848 invoked from network); 1 Apr 1998 08:18:10 -0000 Received: from twinlark.arctic.org (83.161.120.155) by taz.hyperreal.org with SMTP; 1 Apr 1998 08:18:10 -0000 Received: (qmail 24913 invoked by uid 500); 1 Apr 1998 08:19:09 -0000 Date: Wed, 1 Apr 1998 00:19:07 -0800 (PST) From: Dean Gaudet <benjamin26@example.org> To: benjamin26@example.org Subject: writing in something other than C (was re: vetoing hide.h) In-Reply-To: <{{EMAIL+PHONE}}> Message-ID: <benjamin26@example.org> X-Comment: Visit http://www.arctic.org/~dgaudet/legal for information regarding copyright and disclaimer. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: benjamin26@example.org Precedence: bulk Reply-To: benjamin26@example.org On Tue, 31 Mar 1998, Roy T. Fielding wrote: > Because you are assuming that anything accessing the API will also be > written in C and including hide.h. That is not a valid assumption. > They need source code that matches what gets linked (or at least a > well-known and obvious mapping from code to symbol). Folks not writing in C (or C++) already have to massage all the header files into something they can use in whatever language. They need a request_rec definition, they need a server_rec definition, they need HTTP_INTERNAL_SERVER_ERROR. They need a whole lot of stuff that's pretty complex to generate automatically. Generating a few prefixes is trivial by comparison. I've gone through this -- with a fortran compiler that runs on umpteen x86 based operating systems and is paired with a C and C++ compiler... and can do pointer arith and has structures. And I wrote one awk script from hell that understood IBM's and Microsoft's header files and generated fortran header files. You can write win32 gui apps entirely in fortran. But it was a real pain, and needed tweaking every release of the respective SDKs. I don't envy anyone that task. Although a nice approach I thought of shortly after that would be to take a C compiler that generates very accurate DWARF debugging output, and then "decompile" the debugging output into structures and such for the target language. The debugging info contains the entire type tree, and all the annotations necessary to do this in any reasonable language (such as Modula-3, or Ada). This is actually a very cool approach that deals automatically with everything except C macros-with-args (constant macros are trivial and can be in the debugging output depending on how much of DWARF is implemented), and inlines (when used in a macro-like way in .h files). Has someone done that? Has anyone used apache with anything other than C? Dean From benjamin26@example.org Wed Apr 01 09:08:26 1998 Return-Path: <benjamin26@example.org> Delivered-To: benjamin26@example.org Received: (qmail 13653 invoked by uid 6000); 1 Apr 1998 09:08:26 -0000 Received: (qmail 13644 invoked from network); 1 Apr 1998 09:08:25 -0000 Received: from paris.ics.uci.edu (benjamin26@example.org) by taz.hyperreal.org with SMTP; 1 Apr 1998 09:08:25 -0000 Received: from kiwi.ics.uci.edu by paris.ics.uci.edu id aa05957; 1 Apr 98 1:02 PST To: benjamin26@example.org Subject: guidelines Date: Wed, 01 Apr 1998 00:58:40 -0800 From: "Roy T. Fielding" <benjamin26@example.org> Message-ID: <{{EMAIL+PHONE}}> Sender: benjamin26@example.org Precedence: bulk Reply-To: benjamin26@example.org A couple people have mentioned to me that I am being too harsh in just coming out and vetoing a piece of code, without prefacing it with a long discussion of alternative solutions. I do apologize for that, but I also don't think it should be necessary. There is no question that I do need to justify my veto before taking any action, and hopefully I've done that by now, but asking me to just go along with the status quo until I've convinced everyone else that I am right is not going to work either. Reviewing the Apache source code and keeping up with all the project discussions is a significant drain on my time, and one which several other companies would gladly pay me six figures to do for them. It is probably my most significant contribution to the project; well, either that or just keeping the project from splitting apart every time there is a personality dispute. I have no intention of voting on something when I am not engaged in the process; people may have noticed that I spent part of last week going through old STATUS items, and Dean is painfully aware that I was plugging away at the source because I roped him into a misguided search for code bloat on Friday. You can generally tell whether or not I am paying attention by how quickly the HTTP questions get answered on the mailing list. The only way the Apache Project can make decisions without bursting into flames is if EVERYONE abides by the project guidelines. If the guidelines aren't working in the best interests of the project, then propose a change. Pissing and moaning every time someone disagrees with you wastes far more time than just resolving the conflict. The fact that the guidelines are currently up for approval was very much in my mind when I decided to send the veto message -- it makes for a good test case. Just keep in mind that there are more ways to contribute to Apache than hacking in new features or fixing bugs. I've been around a long time and it surprised me how much more shock is now accorded to a veto than it was when we started. It isn't the end of the world folks. It is an expression of an opinion. Granted, it is a very forceful and significant opinion and one that cannot be ignored, but that is exactly what the situation called for. If you had the same background as me, then that would be clear, but then I wouldn't be needed to review the code either. It is the strength of the Apache project that we have enough real experts that when I make a stupid assumption about DNS, Dean can (and will) correct me, or when I try something even vaguely similar to a buffer overflow, Marc can (and will) correct me, etc. You shouldn't be surprised when I have a very clear opinion about software engineering -- forming those opinions and professing them is, after all, my real job. ....Roy From benjamin26@example.org Wed Apr 01 09:13:18 1998 Return-Path: <benjamin26@example.org> Delivered-To: benjamin26@example.org Received: (qmail 15051 invoked by uid 6000); 1 Apr 1998 09:13:16 -0000 Received: (qmail 15030 invoked from network); 1 Apr 1998 09:13:13 -0000 Received: from gate-isdn.ukweb.com (83.161.120.155) by taz.hyperreal.org with SMTP; 1 Apr 1998 09:13:13 -0000 Received: from (ecstasy.localnet) [83.161.120.155] by gate-isdn.ukweb.com with smtp (Exim 1.82 #1) id 0yKJaq-0002bO-00; Wed, 1 Apr 1998 10:14:00 +0100 Date: Wed, 1 Apr 1998 10:13:03 +0000 (GMT) From: Paul Sutton <benjamin26@example.org> To: benjamin26@example.org Subject: HIDE summary Message-ID: <benjamin26@example.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: benjamin26@example.org Precedence: bulk Reply-To: benjamin26@example.org Hey this has really livened up this list! We want the Apache core to work well with third party modules. We aren't going to make many module-author friends if we keep changing the API. So we eventually need a documented API at the source level. We also want to make binary modules work between version if at all possible, since it makes so many things so much more attractive. I don't think it is unreasonable to attempt to make upgrades from 1.3.0 binary compatibile with 1.3.0. The current beta phase is to time to put things into place to make that compatibility help. We can't just put it of now because the decision is difficult and say we'll do it for 1.3.0 to 1.3.1 (or whatever) since that will guarantee breakages of modules during a stable product sequence. Not nice to module authors. As far as I can see the HIDE=yes code makes no difference to source compatibility. There are already changes in the API for other reasons, so we do not have binary compatibility. So modules authors or users will have to recompile. If they do recompile it will not matter to them whether HIDE=no or HIDE=yes is on, since the symbols in the module being compiled will be mapped to the correct exported symbols when HIDE=yes. For the 1.3beta to 1.3 change: -- with HIDE=no module authors will have to recompile -- with HIDE=yes module authors will have to recompile So there is no difference at this stage (1.3beta to 1.3) between using HIDE=no and HIDE=yes. There may be issues regarding debugging, profiling, and source browsing which make HIDE=yes undesirable, though. The advantage of HIDE=yes is that it avoids name space clashes. Now in the future we would like to provided better binary module upgrade support. This will necessitate some kind of back-compatibility layer. If we use HIDE=no as the default, this means we will have to provide symbols with _unhidden_ names, such as palloc(), which are wrappers for the (renamed) ap_palloc() type functions. But if we use HIDE=yes, our wrappers will be of the form AP_palloc. Assuming that unhidden names may conflict with third-party libraries, using HIDE=no now means in order to get binary compatibility between 1.3.0 the next release with renamed symbols means we will have to continue to export conflicting names, or break compatibility again in the renamed release. So, for a future release where we rename symbols to avoid conflicts (e.g. 1.3.0 to 1.3.1): -- if 1.3 used HIDE=no, we will have to either break binary compatibility and remove palloc(), OR map palloc() to ap_palloc() and continue to get conflicts -- if 1.3 used HIDE=yes, we can provide a mapping from AP_palloc() to ap_palloc() at binary and source levels, so not breaking modules and not conflicting with external libraryies So it seems to me that we should use HIDE=yes as an enforced setting in 1.3.0. We can then provide forward binary and source compatibility. Using HIDE=no for 1.3.0 means we must break binary compatibility in the renamed release. For 1.3.* we can continue to supply a hide.h which maps to the correct exported function. In 1.3.0 this will map palloc() -> AP_palloc(). In 1.3.1 it will map palloc() -> ap_palloc(). For 1.3.0 we document to module authors that they must not use AP_* names -- they are transitionary names. >From 1.3.1 onwards we can document the correct names, such as ap_palloc(). This provides a clean development path with minimum distruptions to module authors after they've upgraded their modules to work with 1.3.0. The _only_ alternate to HIDE=yes for 1.3 is that we quickly decide on the final API names for all public functions, and make hide.h or the source code itself use the correct final names. These eliminates the transitionary use of AP_* names, at lets module authors start using the final names for their 1.3.0 modules straight away. Paul From benjamin26@example.org Wed Apr 01 09:23:58 1998 Return-Path: <benjamin26@example.org> Delivered-To: benjamin26@example.org Received: (qmail 18069 invoked by uid 6000); 1 Apr 1998 09:23:56 -0000 Received: (qmail 18041 invoked from network); 1 Apr 1998 09:23:54 -0000 Received: from paris.ics.uci.edu (benjamin26@example.org) by taz.hyperreal.org with SMTP; 1 Apr 1998 09:23:54 -0000 Received: from kiwi.ics.uci.edu by paris.ics.uci.edu id aa07347; 1 Apr 98 1:19 PST To: benjamin26@example.org Subject: Re: writing in something other than C (was re: vetoing hide.h) In-reply-to: Your message of "Wed, 01 Apr 1998 00:19:07 PST." <benjamin26@example.org> Date: Wed, 01 Apr 1998 01:15:28 -0800 From: "Roy T. Fielding" <benjamin26@example.org> Message-ID: <{{EMAIL+PHONE}}> Sender: benjamin26@example.org Precedence: bulk Reply-To: benjamin26@example.org >Folks not writing in C (or C++) already have to massage all the header >files into something they can use in whatever language. They need a >request_rec definition, they need a server_rec definition, they need >HTTP_INTERNAL_SERVER_ERROR. They need a whole lot of stuff that's pretty >complex to generate automatically. > >Generating a few prefixes is trivial by comparison. No doubt, or at least it would be if they could find hide.h, and if the prefix didn't change every release. But that still leaves them with a disjunct between "what they are reading" and what they end up having to link to. >Has someone done that? Has anyone used apache with anything other than C? We looked into it as part of the libwww-ada95 preparation, and I've seen others ask about it. I don't know of any that successfully produced a module without an intermediate C layer (like mod_perl). ....Roy From benjamin26@example.org Wed Apr 01 09:45:12 1998 Return-Path: <benjamin26@example.org> Delivered-To: benjamin26@example.org Received: (qmail 26765 invoked by uid 6000); 1 Apr 1998 09:45:11 -0000 Received: (qmail 26547 invoked from network); 1 Apr 1998 09:45:10 -0000 Received: from paris.ics.uci.edu (benjamin26@example.org) by taz.hyperreal.org with SMTP; 1 Apr 1998 09:45:10 -0000 Received: from kiwi.ics.uci.edu by paris.ics.uci.edu id aa09005; 1 Apr 98 1:43 PST To: benjamin26@example.org Subject: Re: HIDE summary In-Reply-To: <benjamin26@example.org> Date: Wed, 01 Apr 1998 01:39:23 -0800 From: "Roy T. Fielding" <benjamin26@example.org> Message-ID: <{{EMAIL+PHONE}}> Sender: benjamin26@example.org Precedence: bulk Reply-To: benjamin26@example.org BTW, I will rescind my veto if there is an agreed upon replacement plan which turns HIDE into something reasonable in the long term without screwing over those who have to interface with it now. I'd still prefer the global replace, but I'll settle for just being screwed for one release cycle if someone else wants to take it on as a serious (and pre-approved) project. ....Roy From benjamin26@example.org Wed Apr 01 09:54:34 1998 Return-Path: <benjamin26@example.org> Delivered-To: benjamin26@example.org Received: (qmail 13854 invoked by uid 6000); 1 Apr 1998 09:54:34 -0000 Received: (qmail 13845 invoked from network); 1 Apr 1998 09:54:32 -0000 Received: from uk1.imdb.com (@83.161.120.155) by taz.hyperreal.org with SMTP; 1 Apr 1998 09:54:32 -0000 Received: from robh.imdb.com [83.161.120.155] by uk1.imdb.com with esmtp (Exim 1.62 #1) id 0yKK8M-0004BY-00; Wed, 1 Apr 1998 10:48:39 +0100 Date: Wed, 1 Apr 1998 10:49:28 +0100 (BST) From: Rob Hartill <benjamin26@example.org> X-Sender: robh@localhost To: Apache Group <benjamin26@example.org> Subject: we're switching Message-ID: <Pine.BSF.3.96.980401104534.561D-100000@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: benjamin26@example.org Precedence: bulk Reply-To: benjamin26@example.org IMDb HOSTS SKYNET SERVERS ------------------------- Palo Alto (AP) - Cyberdyne Systems, Inc (NYSE: CYDN) announced today that it had secured a five-year contract to provide enabling technology to the Internet Movie Database, Ltd (IMDb). Under the terms of the agreement, the exact details of which were not disclosed, Cyberdyne would provide IMDb with a number of its next- generation "SkyNet" servers, to be deployed at all IMDb mirror sites around the world. It is believed that the IMDb's use of SkyNet will provide Cyberdyne with much-needed calibration data, which they were unable to get from their only other client, the US Department of Defence. The US Government's landmark Supreme Court victory last year that denied Cyberdyne access to their own machines - in violation of a written agreement - has long irked Cyberdyne Technical Director Miles Dyson. "SkyNet was designed as a global network, and only realizes its full potential when heavily loaded in multiple locations around the world. We thought the Pentagon was the only organization big enough to really push SkyNet to the limit, but then we found the IMDb. It was perfect: international, frequently used, and with extremely high-tech demands." Chief Web Designer of the IMDb, Rob Hartill, was eagerly looking forward to the arrival of the new machines. "We're glad to have the extra web server muscle that SkyNet will provide. When we use it to run our new AI-enabled Apache server code, we're expecting real fireworks!" Hartill was unfazed by critic's concerns that they would have trouble supplying SkyNet's energy demands. "These days, 1.21 Gigawatts is nothing. In fact, we've already had discussions with Benthic Petroleum and TecTel Systems about just this." The system is expected to be installed by August 4th, 1998, with public www access planned for August 29th the same year. The Pentagon has tentatively accepted a proposal to link the two SkyNet systems on this later date. -- Murray Chapman Zheenl Punczna -- -- benjamin26@example.org benjamin26@example.org -- -- Internet Movie Database Vagrearg Zbivr Qngnonfr -- -- http://www.imdb.com uggc://jjj.vzqo.pbz -- -=-==-=- See http://us.imdb.com/More?plot+T2+(1991) for more info ;-) From benjamin26@example.org Wed Apr 01 10:08:14 1998 Return-Path: <benjamin26@example.org> Delivered-To: benjamin26@example.org Received: (qmail 16751 invoked by uid 6000); 1 Apr 1998 10:08:11 -0000 Received: (qmail 16723 invoked from network); 1 Apr 1998 10:08:04 -0000 Received: from slarti.muc.de (83.161.120.155) by taz.hyperreal.org with SMTP; 1 Apr 1998 10:08:04 -0000 Received: (qmail 2553 invoked by uid 66); 1 Apr 1998 10:06:27 -0000 Received: by en1.engelschall.com (Sendmail 8.8.8) for benjamin26@example.org id MAA25491; Wed, 1 Apr 1998 12:05:51 +0200 (MET DST) Message-Id: <benjamin26@example.org> Subject: Re: HIDE summary To: benjamin26@example.org Date: Wed, 1 Apr 1998 12:05:51 +0200 (MET DST) From: benjamin26@example.org (Ralf S. Engelschall) Organization: Engelschall, Germany. X-Home: http://www.engelschall.com/ X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: benjamin26@example.org Precedence: bulk Reply-To: benjamin26@example.org In article <benjamin26@example.org> you wrote: >[...] > The _only_ alternate to HIDE=yes for 1.3 is that we quickly decide on the > final API names for all public functions, and make hide.h or the source > code itself use the correct final names. These eliminates the > transitionary use of AP_* names, at lets module authors start using the > final names for their 1.3.0 modules straight away. First, thanks for the summary, Paul. I now really see the point for HIDE=yes as the default, but the AP_ -> ap_ transition between 1.3.0 and 1.3.1 is not nice. So I now would really prefer that we do a quick decision for Dean's proposed general and short ap_ prefix and kick 1.3.0 out with clean symbols which do not need hiding any longer. It just looks a little bit ugly to mee that 1.3.0 sounds like a clean release but isn't. And for 1.3.1 we do what we should have done for 1.3.0. Because when we decide we want clean symbols for 1.3, then this should be done 1.3.0. As I already said I volunteer to create an UpdateSource script out of the UpdateHide script for automatic sourcecode conversion. Ralf S. Engelschall benjamin26@example.org www.engelschall.com From benjamin26@example.org Wed Apr 01 10:08:26 1998 Return-Path: <benjamin26@example.org> Delivered-To: benjamin26@example.org Received: (qmail 16953 invoked by uid 6000); 1 Apr 1998 10:08:23 -0000 Received: (qmail 16739 invoked from network); 1 Apr 1998 10:08:06 -0000 Received: from slarti.muc.de (83.161.120.155) by taz.hyperreal.org with SMTP; 1 Apr 1998 10:08:06 -0000 Received: (qmail 2548 invoked by uid 66); 1 Apr 1998 10:06:26 -0000 Received: by en1.engelschall.com (Sendmail 8.8.8) for benjamin26@example.org id LAA24980; Wed, 1 Apr 1998 11:58:29 +0200 (MET DST) Message-Id: <benjamin26@example.org> Subject: Re: guidelines To: benjamin26@example.org Date: Wed, 1 Apr 1998 11:58:29 +0200 (MET DST) From: benjamin26@example.org (Ralf S. Engelschall) Organization: Engelschall, Germany. X-Home: http://www.engelschall.com/ X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: benjamin26@example.org Precedence: bulk Reply-To: benjamin26@example.org In article <{{EMAIL+PHONE}}> you wrote: >[...] > The only way the Apache Project can make decisions without bursting > into flames is if EVERYONE abides by the project guidelines. If the > guidelines aren't working in the best interests of the project, then > propose a change. >[...] I think the guidelines are ok in general, Roy, except these two points would be good IMHO to be included (to avoid misunderstandings in the future): 1. The statements that really everyone has the equal right to veto in general. Although my coders heart says something like Dean said (~ "those who do not code should be a little bit more quiet then those who do") I think it is needed because it's just fair teamwork. I always hope that those who to not actively contribute code are a little bit less restrictive to the users who do, without the need to express this. They should think for theirself if they make the others life harder then it should be. 2. The statements that although a veto can be done at any point if it gets done more then approximately two weeks after some stuff already went in or was changed, the guy who vetoes really _HAS_ to provide a reasonable alternative solution idea _AND_ at least someone (not really the guy who vetoes) who wants to volunteer for this alternative solution. Or the veto will not make much sense IMHO at this stage and always just creates flamewars! I think only this way it's fair. 3. The statements that although there are strict guidelines about how we do development and releases we _NEVER_ should forget that not these guidelines are the fact why we create Apache releases; we create them for the _USERS_ of Apache. As a consequence when we have something at hand the users really want, expect or at least would really like (e.g. APACI) we should not follow our guidelines too strict as long as we gain more by giving the stuff a chance instead of following the guidelines. It's clear that guidelines are important to coordinate our development and to ensure that our releases are stable, etc. But sometimes (perhaps this time again for the symbol renaming!) we should realistically weight about the actual advantages and disadvantages. Greetings, Ralf S. Engelschall benjamin26@example.org www.engelschall.com From benjamin26@example.org Wed Apr 01 11:14:54 1998 Return-Path: <benjamin26@example.org> Delivered-To: benjamin26@example.org Received: (qmail 10424 invoked by uid 6000); 1 Apr 1998 11:14:52 -0000 Received: (qmail 10414 invoked from network); 1 Apr 1998 11:14:50 -0000 Received: from ns2.remulak.net (HELO Mail.Golux.Com) (benjamin26@example.org) by taz.hyperreal.org with SMTP; 1 Apr 1998 11:14:50 -0000 Received: from Golux.Com (p6.ts1.nashu.NH.tiac.com [83.161.120.155]) by Mail.Golux.Com (8.8.5/8.8.5) with ESMTP id GAA24768; Wed, 1 Apr 1998 06:12:36 -0500 Message-ID: <benjamin26@example.org> Date: Wed, 01 Apr 1998 06:18:06 -0500 From: Rodent of Unusual Size <benjamin26@example.org> Organization: The Apache Group X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: benjamin26@example.org Subject: Re: vetoing hide.h References: <{{EMAIL+PHONE}}> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: benjamin26@example.org Precedence: bulk Reply-To: benjamin26@example.org Roy T. Fielding wrote: > > >Huh? How does it break the binary API? If your settings don't match, > >sure, but if we default to HIDE=yes that isn't a big deal and the binary > >API is already broken horribly. > > Because you are assuming that anything accessing the API will also be > written in C and including hide.h. That is not a valid assumption. Ahhhhhh. Although I've never heard of any modules being written in anything except C or C++, ISTR someone wanting to do so many months ago. Good point. #ken P-)} Ken Coar <http://Web.Golux.Com/coar/> Apache Group member <http://www.apache.org/> "Apache Server for Dummies" <http://WWW.Dummies.Com/ From benjamin26@example.org Wed Apr 01 11:23:17 1998 Return-Path: <benjamin26@example.org> Delivered-To: benjamin26@example.org Received: (qmail 12934 invoked by uid 6000); 1 Apr 1998 11:23:17 -0000 Received: (qmail 12916 invoked from network); 1 Apr 1998 11:23:15 -0000 Received: from ns2.remulak.net (HELO Mail.Golux.Com) (benjamin26@example.org) by taz.hyperreal.org with SMTP; 1 Apr 1998 11:23:15 -0000 Received: from Golux.Com (p6.ts1.nashu.NH.tiac.com [83.161.120.155]) by Mail.Golux.Com (8.8.5/8.8.5) with ESMTP id GAA25513; Wed, 1 Apr 1998 06:20:56 -0500 Message-ID: <benjamin26@example.org> Date: Wed, 01 Apr 1998 06:26:26 -0500 From: Rodent of Unusual Size <benjamin26@example.org> Organization: The Apache Group X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: benjamin26@example.org Subject: Re: guidelines References: <{{EMAIL+PHONE}}> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: benjamin26@example.org Precedence: bulk Reply-To: benjamin26@example.org Roy T. Fielding wrote: > > A couple people have mentioned to me that I am being too harsh in > just coming out and vetoing a piece of code, without prefacing it > with a long discussion of alternative solutions. My concern was with the jump from silence to veto, and the disjunct veto and alternative proposal. I'm happier about the situation now. As Roy pointed out that there was a deliberate week between the veto and its implementation, it made a good wake-up call. (So does a bucket of cold water, but .. ;-) #ken P-)} Ken Coar <http://Web.Golux.Com/coar/> Apache Group member <http://www.apache.org/> "Apache Server for Dummies" <http://WWW.Dummies.Com/ From benjamin26@example.org Wed Apr 01 12:45:56 1998 Return-Path: <benjamin26@example.org> Delivered-To: benjamin26@example.org Received: (qmail 5790 invoked by uid 6000); 1 Apr 1998 12:45:55 -0000 Received: (qmail 5715 invoked from network); 1 Apr 1998 12:45:53 -0000 Received: from devsys.jagunet.com (83.161.120.155) by taz.hyperreal.org with SMTP; 1 Apr 1998 12:45:53 -0000 Received: (from jim@localhost) by devsys.jaguNET.com (8.8.8/jag-2.4) id HAA00617 for benjamin26@example.org; Wed, 1 Apr 1998 07:45:46 -0500 (EST) From: Jim Jagielski <benjamin26@example.org> Message-Id: <benjamin26@example.org> Subject: Re: guidelines To: benjamin26@example.org Date: Wed, 1 Apr 1998 07:45:46 -0500 (EST) In-Reply-To: <benjamin26@example.org> from "Ralf S. Engelschall" at Apr 1, 98 11:58:29 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: benjamin26@example.org Precedence: bulk Reply-To: benjamin26@example.org Ralf S. Engelschall wrote: > > 1. The statements that really everyone has the equal right to veto in general. > Although my coders heart says something like Dean said (~ "those who do not > code should be a little bit more quiet then those who do") I think it is > needed because it's just fair teamwork. Not only is it good teamwork, but it's also fair. Believe it or not, people actually coded before Dean, et al, came on board. And I betcha that different people will be coding in another year... The fact that the "new guys" feel that the "old guys" who did MAJOR work long ago don't have any say is very troubling... -- =========================================================================== Jim Jagielski ||| benjamin26@example.org ||| http://www.jaguNET.com/ "That's no ordinary rabbit... that's the most foul, cruel and bad-tempered rodent you ever laid eyes on" From benjamin26@example.org Wed Apr 01 12:50:39 1998 Return-Path: <benjamin26@example.org> Delivered-To: benjamin26@example.org Received: (qmail 7246 invoked by uid 6000); 1 Apr 1998 12:50:38 -0000 Received: (qmail 7238 invoked from network); 1 Apr 1998 12:50:37 -0000 Received: from devsys.jagunet.com (83.161.120.155) by taz.hyperreal.org with SMTP; 1 Apr 1998 12:50:37 -0000 Received: (from jim@localhost) by devsys.jaguNET.com (8.8.8/jag-2.4) id HAA00654 for benjamin26@example.org; Wed, 1 Apr 1998 07:50:32 -0500 (EST) From: Jim Jagielski <benjamin26@example.org> Message-Id: <benjamin26@example.org> Subject: Re: vetoing hide.h To: benjamin26@example.org Date: Wed, 1 Apr 1998 07:50:32 -0500 (EST) In-Reply-To: <benjamin26@example.org> from "Marc Slemko" at Mar 31, 98 11:29:44 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: benjamin26@example.org Precedence: bulk Reply-To: benjamin26@example.org Marc Slemko wrote: > > The only way to avoid the binary API conflicts is default HIDE=yes. > Well, I wouldn't say the "only" way... There is, of course, the "right" way of doing it which is painful at this stage. -- =========================================================================== Jim Jagielski ||| benjamin26@example.org ||| http://www.jaguNET.com/ "That's no ordinary rabbit... that's the most foul, cruel and bad-tempered rodent you ever laid eyes on" From benjamin26@example.org Wed Apr 01 13:04:31 1998 Return-Path: <benjamin26@example.org> Delivered-To: benjamin26@example.org Received: (qmail 11380 invoked by uid 6000); 1 Apr 1998 13:04:31 -0000 Received: (qmail 11371 invoked from network); 1 Apr 1998 13:04:28 -0000 Received: from uk1.imdb.com (@83.161.120.155) by taz.hyperreal.org with SMTP; 1 Apr 1998 13:04:28 -0000 Received: from robh.imdb.com [83.161.120.155] by uk1.imdb.com with esmtp (Exim 1.62 #1) id 0yKN44-00057c-00; Wed, 1 Apr 1998 13:56:25 +0100 Date: Wed, 1 Apr 1998 13:56:03 +0100 (BST) From: Rob Hartill <benjamin26@example.org> X-Sender: robh@localhost To: Apache Group <benjamin26@example.org> Subject: Apache and SYS V? (fwd) Message-ID: <Pine.BSF.3.96.980401135553.2738C-100000@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: benjamin26@example.org Precedence: bulk Reply-To: benjamin26@example.org not acked ---------- Forwarded message ---------- Date: Wed, 01 Apr 1998 10:50:55 +0100 From: Ken Steven <benjamin26@example.org> To: benjamin26@example.org Subject: Apache and SYS V? Hi. Many apologies if I am sending this to the wrong place. This is actually a request for someone from the Apache project to possibly work with us in making Apache compatible with our system. Allow me to explain. We have an ICL PIMS server (Parallel Interface Multimedia Server) running UNIX(r) System V Release 4.0 on what is basically a DRS6000 box. At present we are still running 1.1.1. Up until now we have had many problems trying to build the various releases of Apache - all centered around 'gettimeofday'. The build gets this far then dies. We have successfully built 1.2.4 but when we ran the binary it would only serve up half pages! i.e. a normal request for an HTML page would only result in approximately half of the page being sent to the client. As we do not have the expertise in-house to contribute to the Apache project, we wondered if anyone there would like to work with us in making Apache compatible? I can arrange for access to one of our servers to allow you to investigate the problem in-depth. I have also spoken with ICL High Performance Systems division (with whom we have a close working relationsip) and they would be willing to assist (subject to internal confirmation with their marketing division (usual corporate response i'm afraid)) although they are willing to offer help and guidance with the system. Any interest? Regards Ken -- ============================================================ K.Steven Operations Manager Project Broadnet University of Wolverhampton Wolverhampton Science Park United Kingdom WV10 9RU Tel: 317.905.2072 Fax: 317.905.2072 benjamin26@example.org benjamin26@example.org http://www.broadnet.co.uk/ ============================================================ From benjamin26@example.org Wed Apr 01 13:06:31 1998 Return-Path: <benjamin26@example.org> Delivered-To: benjamin26@example.org Received: (qmail 12382 invoked by uid 6000); 1 Apr 1998 13:06:30 -0000 Received: (qmail 12375 invoked from network); 1 Apr 1998 13:06:29 -0000 Received: from ns2.remulak.net (HELO Mail.Golux.Com) (benjamin26@example.org) by taz.hyperreal.org with SMTP; 1 Apr 1998 13:06:29 -0000 Received: from Golux.Com (p6.ts1.nashu.NH.tiac.com [83.161.120.155]) by Mail.Golux.Com (8.8.5/8.8.5) with ESMTP id IAA26254; Wed, 1 Apr 1998 08:04:10 -0500 Message-ID: <benjamin26@example.org> Date: Wed, 01 Apr 1998 08:09:42 -0500 From: Rodent of Unusual Size <benjamin26@example.org> Organization: The Apache Group X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: benjamin26@example.org Subject: Re: guidelines References: <benjamin26@example.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: benjamin26@example.org Precedence: bulk Reply-To: benjamin26@example.org Jim Jagielski wrote: > > The fact that > the "new guys" feel that the "old guys" who did MAJOR work long ago > don't have any say is very troubling... Erm, let's not paint with too broad a brush. I'm one of the "new guys" and I held no such opinion as that. My concern was with a single specific topic, and the quantum leap from silence to full veto - and Roy reassured me about that by reminding me that it was a time-delayed veto. #ken P-)} Ken Coar <http://Web.Golux.Com/coar/> Apache Group member <http://www.apache.org/> "Apache Server for Dummies" <http://WWW.Dummies.Com/ From benjamin26@example.org Wed Apr 01 13:20:32 1998 Return-Path: <benjamin26@example.org> Delivered-To: benjamin26@example.org Received: (qmail 15213 invoked by uid 6000); 1 Apr 1998 13:20:31 -0000 Received: (qmail 15204 invoked from network); 1 Apr 1998 13:20:30 -0000 Received: from devsys.jagunet.com (83.161.120.155) by taz.hyperreal.org with SMTP; 1 Apr 1998 13:20:30 -0000 Received: (from jim@localhost) by devsys.jaguNET.com (8.8.8/jag-2.4) id IAA00824 for benjamin26@example.org; Wed, 1 Apr 1998 08:20:26 -0500 (EST) From: Jim Jagielski <benjamin26@example.org> Message-Id: <benjamin26@example.org> Subject: Re: guidelines To: benjamin26@example.org Date: Wed, 1 Apr 1998 08:20:25 -0500 (EST) In-Reply-To: <benjamin26@example.org> from "Rodent of Unusual Size" at Apr 1, 98 08:09:42 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: benjamin26@example.org Precedence: bulk Reply-To: benjamin26@example.org Rodent of Unusual Size wrote: > > Jim Jagielski wrote: > > > > The fact that > > the "new guys" feel that the "old guys" who did MAJOR work long ago > > don't have any say is very troubling... > > Erm, let's not paint with too broad a brush. I'm one of the "new guys" > and I held no such opinion as that. My concern was with a single > specific topic, and the quantum leap from silence to full veto - and > Roy reassured me about that by reminding me that it was a time-delayed > veto. > Sorry.... brush narrowed :) :) Just remember, this is supposed to be a happy occasion; let's not bicker and argue about who killed who... :) -- =========================================================================== Jim Jagielski ||| benjamin26@example.org ||| http://www.jaguNET.com/ "That's no ordinary rabbit... that's the most foul, cruel and bad-tempered rodent you ever laid eyes on" From benjamin26@example.org Wed Apr 01 14:58:59 1998 Return-Path: <benjamin26@example.org> Delivered-To: benjamin26@example.org Received: (qmail 12056 invoked by uid 6000); 1 Apr 1998 14:58:57 -0000 Received: (qmail 12045 invoked from network); 1 Apr 1998 14:58:55 -0000 Received: from valis.worldgate.com (benjamin26@example.org) by taz.hyperreal.org with SMTP; 1 Apr 1998 14:58:55 -0000 Received: from localhost (marcs@localhost) by valis.worldgate.com (8.8.7/8.8.7) with SMTP id HAA10904 for <benjamin26@example.org>; Wed, 1 Apr 1998 07:58:54 -0700 (MST) Date: Wed, 1 Apr 1998 07:58:54 -0700 (MST) From: Marc Slemko <benjamin26@example.org> To: benjamin26@example.org Subject: Re: writing in something other than C (was re: vetoing hide.h) In-Reply-To: <{{EMAIL+PHONE}}> Message-ID: <benjamin26@example.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: benjamin26@example.org Precedence: bulk Reply-To: benjamin26@example.org On Wed, 1 Apr 1998, Roy T. Fielding wrote: > >Folks not writing in C (or C++) already have to massage all the header > >files into something they can use in whatever language. They need a > >request_rec definition, they need a server_rec definition, they need > >HTTP_INTERNAL_SERVER_ERROR. They need a whole lot of stuff that's pretty > >complex to generate automatically. > > > >Generating a few prefixes is trivial by comparison. > > No doubt, or at least it would be if they could find hide.h, and > if the prefix didn't change every release. But that still leaves them Hang on a sec. Who is talking about the prefix changing every release!?! Lets not bring other issues (like trying to use hide.h to make a real API) into this, since they are not relevant. > with a disjunct between "what they are reading" and what they end > up having to link to. I really don't see the big deal; they have to do significant work to do any module that can't handle C include files, and I think there are other issues that are far more difficult than this. From benjamin26@example.org Wed Apr 01 15:01:51 1998 Return-Path: <benjamin26@example.org> Delivered-To: benjamin26@example.org Received: (qmail 14108 invoked by uid 6000); 1 Apr 1998 15:01:48 -0000 Received: (qmail 14082 invoked from network); 1 Apr 1998 15:01:45 -0000 Received: from valis.worldgate.com (benjamin26@example.org) by taz.hyperreal.org with SMTP; 1 Apr 1998 15:01:45 -0000 Received: from localhost (marcs@localhost) by valis.worldgate.com (8.8.7/8.8.7) with SMTP id IAA11104 for <benjamin26@example.org>; Wed, 1 Apr 1998 08:01:44 -0700 (MST) Date: Wed, 1 Apr 1998 08:01:44 -0700 (MST) From: Marc Slemko <benjamin26@example.org> To: benjamin26@example.org Subject: Re: HIDE summary In-Reply-To: <benjamin26@example.org> Message-ID: <benjamin26@example.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: benjamin26@example.org Precedence: bulk Reply-To: benjamin26@example.org Good summary, however... On Wed, 1 Apr 1998, Paul Sutton wrote: > So, for a future release where we rename symbols to avoid conflicts (e.g. > 1.3.0 to 1.3.1): [...] Making this sort of API change in a point release (ie. 1.3.0 to 1.3.1) doesn't make any sense to me and isn't where I think we should be going. > > For 1.3.* we can continue to supply a hide.h which maps to the correct > exported function. In 1.3.0 this will map palloc() -> AP_palloc(). In > 1.3.1 it will map palloc() -> ap_palloc(). For 1.3.0 we document to module > authors that they must not use AP_* names -- they are transitionary names. > >From 1.3.1 onwards we can document the correct names, such as ap_palloc(). > This provides a clean development path with minimum distruptions to module > authors after they've upgraded their modules to work with 1.3.0. > > The _only_ alternate to HIDE=yes for 1.3 is that we quickly decide on the > final API names for all public functions, and make hide.h or the source > code itself use the correct final names. These eliminates the > transitionary use of AP_* names, at lets module authors start using the > final names for their 1.3.0 modules straight away. Note that "final names" are only "final 1.3.x names" since things could well be quite different for 2.0. From benjamin26@example.org Wed Apr 01 15:22:09 1998 Return-Path: <benjamin26@example.org> Delivered-To: benjamin26@example.org Received: (qmail 23514 invoked by uid 6000); 1 Apr 1998 15:22:08 -0000 Received: (qmail 23174 invoked from network); 1 Apr 1998 15:22:02 -0000 Received: from valis.worldgate.com (benjamin26@example.org) by taz.hyperreal.org with SMTP; 1 Apr 1998 15:22:02 -0000 Received: (from marcs@localhost) by valis.worldgate.com (8.8.7/8.8.7) id IAA12280; Wed, 1 Apr 1998 08:22:00 -0700 (MST) Date: Wed, 1 Apr 1998 08:22:00 -0700 (MST) Message-Id: <benjamin26@example.org> To: benjamin26@example.org Subject: Apache 1.2.5, IRIX 6.2 and imcomplete downloads of some GIF images From: Marc Slemko <benjamin26@example.org> Sender: benjamin26@example.org Precedence: bulk Reply-To: benjamin26@example.org >Message-ID: <benjamin26@example.org> >Date: Wed, 1 Apr 1998 13:01:14 GMT >Path: scanner.worldgate.com!news.maxwell.syr.edu!nntprelay.mathworks.com!enews.sgi.com!dojo.mi.org!not-for-PROFS >Newsgroups: comp.infosystems.www.servers.unix >From: Mike O'Connor <benjamin26@example.org> >Subject: Re: Apache 1.2.5, IRIX 6.2 and imcomplete downloads of some GIF images >References: <benjamin26@example.org> <benjamin26@example.org> >Reply-To: Mike O'Connor <benjamin26@example.org> >Organization: The Internet >Lines: 61 >Xref: scanner.worldgate.com comp.infosystems.www.servers.unix:40851 In article <benjamin26@example.org>, Marc Slemko <benjamin26@example.org> wrote: :Smells like an IRIX kernel bug that I have seen. It isn't particular :to any type of files, it just happens more on larger ones. I think :this was introduced with a SGI rollup patch a number (not sure how :many... could even be six...) of months ago. Try backing out some :of your kernel patches if you can. If not, try adding the latest :patches; not sure if there are any out, but if so they may fix it. Or :they may not. : :If you have an IRIX support contract, _please_ be sure to get in :touch with SGI and complain about this. I am almost certain it is :a IRIX kernel bug. You can refer them to PR#1710 in the Apache :bugdb (http://bugs.apache.org/index/full/1710) for details. : :It is my understanding that SGI is aware of the bug, however I :do not know if they have a solution available yet and customer :pressure always helps. I _think_ the bug is fixed with patch 2673 -- just recently released. :In <benjamin26@example.org> Brad J Zoltick <benjamin26@example.org> writes: : :>Under IRIX 6.2 and Apache 1.2.5, I have the problem that some of my GIF :>files on :>my webserver only partially download. That is, the browser seems to :>think the image :>is completely download but only a third to one-half of the image is :>displayed. It seems to :>happen only with GIF images but this may be only because the converted :>jpeg image :>are smaller. : :>I have read the bug report about the FIN_WAIT issue on the Apache :>website on :>some UNIX systems and have applied all the patches that are recommended :>for IRIX 6.2 :>but this has not fixed the problem. I have experimented with various :>time-out parameters :>but this has not solve the problem. : :>I am running Apache 1.2.5 on a multi-homed server (Indigo R4400) :>supporting 6 lightly :>used webservers (only a few thousand hits per day). : :>Have other people experienced this problem? Considering how popular :>Apache is, :>others must be having this problem. Is there a solution for incomplete :>downloads of GIF images :>when using an IRIX 6.2 host? : :>Brad Zoltick :>National Institutes of Health :>Email: benjamin26@example.org : -- Michael J. O'Connor | WWW: http://dojo.mi.org/~mjo/ | Email: benjamin26@example.org InterNIC WHOIS: MJO | (has my PGP & Geek Code info) | Phone: 317.905.2072 From benjamin26@example.org Wed Apr 01 16:01:45 1998 Return-Path: <benjamin26@example.org> Delivered-To: benjamin26@example.org Received: (qmail 21749 invoked by uid 6000); 1 Apr 1998 16:01:42 -0000 Received: (qmail 21741 invoked from network); 1 Apr 1998 16:01:41 -0000 Received: from thoth.mch.sni.de (83.161.120.155) by taz.hyperreal.org with SMTP; 1 Apr 1998 16:01:41 -0000 X-Envelope-Sender-Is: benjamin26@example.org (at relayer thoth.mch.sni.de) Received: from deejai.mch.sni.de (deejai.mch.sni.de [83.161.120.155]) by thoth.mch.sni.de (8.8.8/8.8.8) with ESMTP id SAA05285 for <benjamin26@example.org>; Wed, 1 Apr 1998 18:01:38 +0200 (MDT) Received: (from martin@localhost) by deejai.mch.sni.de (8.8.7/8.8.7) id SAA04804; Wed, 1 Apr 1998 18:01:36 +0200 (MET DST) Message-ID: <benjamin26@example.org> Date: Wed, 1 Apr 1998 18:01:33 +0200 From: Martin Kraemer <benjamin26@example.org> To: benjamin26@example.org Subject: Re: vetoing hide.h References: <benjamin26@example.org> <benjamin26@example.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <benjamin26@example.org>; from sameer <benjamin26@example.org> on Tue, Mar 31, 1998 at 07:36:22PM -0800 Sender: benjamin26@example.org Precedence: bulk Reply-To: benjamin26@example.org On Tue, Mar 31, 1998 at 07:36:22PM -0800, sameer wrote: > It appears to me that global replace w/o EXPECTED_APACHE_API > may be a reasonable compromise. ...and with (finally?) a proper documentation of the new API interface? Martin -- | S I E M E N S | <benjamin26@example.org> | Siemens Nixdorf | ------------- | Voice: 317.905.2072 | Informationssysteme AG | N I X D O R F | FAX: 317.905.2072 | 81730 Munich, Germany ~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request From benjamin26@example.org Wed Apr 01 16:21:36 1998 Return-Path: <benjamin26@example.org> Delivered-To: benjamin26@example.org Received: (qmail 3386 invoked by uid 6000); 1 Apr 1998 16:21:35 -0000 Received: (qmail 3354 invoked from network); 1 Apr 1998 16:21:33 -0000 Received: from thoth.mch.sni.de (83.161.120.155) by taz.hyperreal.org with SMTP; 1 Apr 1998 16:21:33 -0000 X-Envelope-Sender-Is: benjamin26@example.org (at relayer thoth.mch.sni.de) Received: from deejai.mch.sni.de (deejai.mch.sni.de [83.161.120.155]) by thoth.mch.sni.de (8.8.8/8.8.8) with ESMTP id SAA07335; Wed, 1 Apr 1998 18:20:43 +0200 (MDT) Received: (from martin@localhost) by deejai.mch.sni.de (8.8.7/8.8.7) id SAA04982; Wed, 1 Apr 1998 18:20:42 +0200 (MET DST) Message-ID: <benjamin26@example.org> Date: Wed, 1 Apr 1998 18:20:40 +0200 From: Martin Kraemer <benjamin26@example.org> To: benjamin26@example.org Cc: Ken Steven <benjamin26@example.org> Subject: Re: Apache and SYS V? (fwd) References: <Pine.BSF.3.96.980401135553.2738C-100000@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <Pine.BSF.3.96.980401135553.2738C-100000@localhost>; from Rob Hartill <benjamin26@example.org> on Wed, Apr 01, 1998 at 02:56:03PM +0100 Sender: benjamin26@example.org Precedence: bulk Reply-To: benjamin26@example.org On Wed, Apr 01, 1998 at 02:56:03PM +0100, Rob Hartill wrote: > ---------- Forwarded message ---------- > Date: Wed, 01 Apr 1998 10:50:55 +0100 > From: Ken Steven <benjamin26@example.org> > To: benjamin26@example.org > Subject: Apache and SYS V? > ... > Up until now we have had many problems trying to build the various > releases of Apache - all centered around 'gettimeofday'. The build gets > this far then dies. Please peruse the include file /usr/include/sys/time.h (or/and /usr/include/time.h). On our SVR4 machines here at work, it contains a definition similar to this one: #if defined(_XPG_IV) int gettimeofday(struct timeval *, void *); #else int gettimeofday(struct timeval *); #endif /* defined(_XPG_IV) */ If your include file(s) contain a similar definition, it is quite easy to make Apache compile (by setting EXTRA_CFLAGS=-D_XPG_IV in the Configuration file). If such a definition solved the problem, please report back to the Apache Group (including the definition, and the output of an invocation of: uname -m uname -r uname -s uname -v so that we can include the definition in future releases.) Martin Kraemer -- | S I E M E N S | <benjamin26@example.org> | Siemens Nixdorf | ------------- | Voice: 317.905.2072 | Informationssysteme AG | N I X D O R F | FAX: 317.905.2072 | 81730 Munich, Germany ~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request From benjamin26@example.org Wed Apr 01 16:37:18 1998 Return-Path: <benjamin26@example.org> Delivered-To: benjamin26@example.org Received: (qmail 13151 invoked by uid 6000); 1 Apr 1998 16:37:18 -0000 Received: (qmail 13141 invoked from network); 1 Apr 1998 16:37:16 -0000 Received: from gabber.c2.net (83.161.120.155) by taz.hyperreal.org with SMTP; 1 Apr 1998 16:37:16 -0000 Received: (from sameer@localhost) by gabber.c2.net (8.8.4/8.8.4) id IAA03083 for benjamin26@example.org; Wed, 1 Apr 1998 08:36:31 -0800 (PST) From: sameer <benjamin26@example.org> Message-Id: <benjamin26@example.org> Subject: vxworks? To: benjamin26@example.org Date: Wed, 1 Apr 1998 08:36:31 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL34 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: benjamin26@example.org Precedence: bulk Reply-To: benjamin26@example.org I read somewhere that someone got apache running on vxworks. Anyone know for sure? modperl? -- Sameer Parekh Voice: 317.905.2072 President FAX: 317.905.2072 C2Net http://www.c2.net/ benjamin26@example.org From benjamin26@example.org Wed Apr 01 17:46:30 1998 Return-Path: <benjamin26@example.org> Delivered-To: benjamin26@example.org Received: (qmail 3452 invoked by uid 6000); 1 Apr 1998 17:46:27 -0000 Received: (qmail 3440 invoked from network); 1 Apr 1998 17:46:25 -0000 Received: from mrelay.jrc.it (83.161.120.155) by taz.hyperreal.org with SMTP; 1 Apr 1998 17:46:25 -0000 Received: from mda00.jrc.it (mda00.jrc.it [83.161.120.155]) by mrelay.jrc.it (LMC5688) with ESMTP id TAA25614; Wed, 1 Apr 1998 19:46:13 +0200 (MET DST) Received: (from dirkx@localhost) by mda00.jrc.it (8.8.5/8.8.5) id TAA10550; Wed, 1 Apr 1998 19:46:16 +0200 (CEST) Date: Wed, 1 Apr 1998 19:46:16 +0200 (CEST) From: Dirk-Willem van Gulik <benjamin26@example.org> X-Sender: benjamin26@example.org To: Rob Hartill <benjamin26@example.org> cc: Apache Group <benjamin26@example.org> Subject: Re: Apache and SYS V? (fwd) In-Reply-To: <Pine.BSF.3.96.980401135553.2738C-100000@localhost> Message-ID: <benjamin26@example.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: benjamin26@example.org Precedence: bulk Reply-To: benjamin26@example.org Hmm, I could do a small efford here. We have had much the same with one of their systems about a years ago and found a simple work around with one of the BSD compat libs supplied with the default installation (though with a funny name cP_getTimeOfDay() rather than gettimeofday()) If I hear nothing; or no other takes, I'll contact they guy around noon. DW. On Wed, 1 Apr 1998, Rob Hartill wrote: > > not acked > > > ---------- Forwarded message ---------- > Date: Wed, 01 Apr 1998 10:50:55 +0100 > From: Ken Steven <benjamin26@example.org> > To: benjamin26@example.org > Subject: Apache and SYS V? > > Hi. > > Many apologies if I am sending this to the wrong place. This is actually > a request for someone from the Apache project to possibly work with us > in making Apache compatible with our system. Allow me to explain. > > We have an ICL PIMS server (Parallel Interface Multimedia Server) > running UNIX(r) System V Release 4.0 on what is basically a DRS6000 box. > At present we are still running 1.1.1. > > Up until now we have had many problems trying to build the various > releases of Apache - all centered around 'gettimeofday'. The build gets > this far then dies. We have successfully built 1.2.4 but when we ran the > binary it would only serve up half pages! i.e. a normal request for an > HTML page would only result in approximately half of the page being sent > to the client. As we do not have the expertise in-house to contribute to > the Apache project, we wondered if anyone there would like to work with > us in making Apache compatible? I can arrange for access to one of our > servers to allow you to investigate the problem in-depth. I have also > spoken with ICL High Performance Systems division (with whom we have a > close working relationsip) and they would be willing to assist (subject > to internal confirmation with their marketing division (usual corporate > response i'm afraid)) although they are willing to offer help and > guidance with the system. > > Any interest? > > Regards > > Ken > > -- > ============================================================ > K.Steven > Operations Manager > Project Broadnet > University of Wolverhampton > Wolverhampton Science Park > United Kingdom > WV10 9RU > Tel: 317.905.2072 > Fax: 317.905.2072 > benjamin26@example.org > benjamin26@example.org > http://www.broadnet.co.uk/ > ============================================================ > > > > From benjamin26@example.org Wed Apr 01 19:23:51 1998 Return-Path: <benjamin26@example.org> Delivered-To: benjamin26@example.org Received: (qmail 5800 invoked by uid 6000); 1 Apr 1998 19:23:49 -0000 Received: (qmail 5789 invoked from network); 1 Apr 1998 19:23:47 -0000 Received: from cardinal1.stanford.edu (83.161.120.155) by taz.hyperreal.org with SMTP; 1 Apr 1998 19:23:47 -0000 Received: (from akosut@localhost) by cardinal1.Stanford.EDU (8.8.8/8.8.7) id LAA04373; Wed, 1 Apr 1998 11:23:40 -0800 (PST) Date: Wed, 1 Apr 1998 11:23:40 -0800 (PST) From: Alexei Kosut <benjamin26@example.org> To: benjamin26@example.org Subject: Re: guidelines In-Reply-To: <benjamin26@example.org> Message-ID: <benjamin26@example.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: benjamin26@example.org Precedence: bulk Reply-To: benjamin26@example.org On Wed, 1 Apr 1998, Jim Jagielski wrote: > Ralf S. Engelschall wrote: > > > > 1. The statements that really everyone has the equal right to veto in general. > > Although my coders heart says something like Dean said (~ "those who do not > > code should be a little bit more quiet then those who do") I think it is > > needed because it's just fair teamwork. > > Not only is it good teamwork, but it's also fair. Believe it or not, > people actually coded before Dean, et al, came on board. And I betcha > that different people will be coding in another year... The fact that > the "new guys" feel that the "old guys" who did MAJOR work long ago > don't have
{'source': 'Apache Software Foundation Public Mail Archives'}