Apologizing now, my comments yesterday stemmed from having a VERY bad. I let it bleed into my postings, and that was wrong.
> From: 'Aaron Bannert' [mailto:[EMAIL PROTECTED] > > On Sat, Jul 13, 2002 at 11:07:57AM -0700, Ryan Bloom wrote: > > Screw that. I have lost votes before, and I can accept that. What is > > pissing me off is that the obvious majority would rather keep > > apr_time_t, but because of a stupid veto, we are being forced to change > > the name. > > "Stupid veto?" Pardon me, but that is the entire point of a veto. > I have a problem with one of the solutions, and I have a valid > technical reason (that you may not agree with). Let's work together > to fix the problem in a way we'll all be happy with. My biggest problem is that this is just getting more and more complex, and the conversation is almost impossible to follow. To the best of my knowledge (from trying to follow the conversation), at this point, we are talking about: Apr_busec_time_t and apr_busec_span_t So, simple question: What is a busec? I obviously know the answer, it is a binary usec. How many of APR users do you honestly expect to look at busec and think that? Now, we are also talking about having macros to convert to and from decimal time values. So, that would essentially be: Apr_busec_sec Apr_busec_usec Apr_busec_msec And corresponding reverse macros: Apr_sec_busec Apr_usec_busec Apr_msec_busec A way to compare and operate on time: Apr_busec_add Apr_busec_sub Now, we still need a way to get to the current time: Apr_busec_now Convert to a human-readable form: Apr_time_exp_tz Apr_explode_time Apr_time_exp_gmt Apr_time_exp_lt Apr_explode_localtime Apr_time_exp_get Convert from human-readable to apr: Apr_implode_gmt Apr_implode_time Apr_time_imp_tz Convert to strings: Apr_rfc22_date Apr_ctime Apr_strftime And finally sleep: Apr_sleep 22 functions/macros to deal with time. 8 of those are because we are storing time in a format that nobody else expects. How does apr_poll deal with time? Does it use apr_busec_interval_t or "number of seconds to wait"? If it uses apr_busec_interval_t, then every single call to poll (and every other apr function that accepts a timeout arg) becomes: Apr_poll(pollset, 1, &nsds, apr_sec_busec(5)); If it accepts "number of seconds to wait", then EVER apr function that accepts a timeout arg needs to do its own conversion. Which, BTW is a bad idea, because keeping it straight when you are using apr_busec_t and when you are using "number of seconds" inside the library will be very difficult to keep track of, and it is almost guaranteed to cause bugs. Either one of these solutions is most likely going to cause enough pain to the developer that APR's time code will be used rarely, IMHO. > > We have provided mechanisms for users to determine if > > their version of APR matches the installed version. > > I know of no APR apps that are currently using these mechanisms, including > httpd. Do you? We provide it, because apps need to start to use it. The timing change would be the perfect excuse to start enforcing it. > > Vetos used to be rare, now they are common. That stops debate, because > > a veto can only be removed by the person who issued it. I have a > > problem with the frequency with which vetos are used in APR and httpd > > development today. We are all supposed to be working together to solve > > a problem, vetos are meant to be used when rational discussion DOESN'T > > come up with a solution. Instead, we use them to head off possible > > solutions that we don't like. > > That is exactly what they are for. Rather than let people go through > the work to come up with something that will be later vetoed, we state > early what we would have a problem with and try to work around it. This No. State it with a comment in e-mail, not a veto. A veto is too confrontational, and they are usually put out there when emotions are high. There was a threatened veto on apr_wait_for_io_or_timeout using apr_poll, because the code would be ugly. But I ignored the veto, and re-wrote apr_poll, which, I think everybody will agree, was the best way to solve the problems. Vetos stop work which could be correct. Discussions allow work to continue taking everybody's opinions into account. If you lay a veto at the beginning of the discussion, it isn't worth following that logic at all anymore, which can stop some very useful ideas from being put out and followed. If you have a civil conversation without the vetos, your opinion continues to be heard, but it is heard in a non-confrontational way, and the discussions keep moving forward. Who knows, you may find that you can live with what you were going to veto, because of some of the other benefits of it. What if somebody had volunteered to write a script that converted all current implementations of apr_time_t to the binary format? Would that have resolved your veto? We'll never know, because the veto was thrown out, so the apr_time_t name was dropped as an option very early on. I don't honestly think such a script could be 100% accurate, but that is just the first thing that came to my head. Maybe would could have had: #ifndef NEW_TIME_FMT #error "Please convert you code to use busec's #endif And removed the #ifndef after a month or two. Would that have resolved the veto. Vetos stop conversations, whereas opinions and civil discussion allow them to continue. The earlier a veto is thrown, the more likely that a perfectly valid technical solution will not be discussed. Ryan
