"Andrew M. Bishop" wrote: > > Miernik <[EMAIL PROTECTED]> writes: > > > On Fri, 6 Sep 2002, Paul A. Rombouts wrote: > > > > > I've made available as a patch file wwwoffle-2.7e-par.diff.gz. > > > The URL for a webpage where this patch is made available can be found at the end > > > of this message. > > > The file wwwoffle-2.7e-par.diff.gz can be used to patch AMB's original version > > > 2.7e source. After that you can study the modifications I've made in the code, > > > but you can also compile, install, and run wwwoffled in the traditional manner. > > > > Will that be incorporated in the next version of WWWOFFLE? > > I'd like it to be. > > The patch that Paul has released will NOT be included in the next > version of WWWOFFLE. ... > > 1) Some changes will definitely not be included. > > These are for example the changes that stop it compiling on anything > except Linux. One of the goals of WWWOFFLE (and all programs that I > write) is portability. This means using standard functions and not > requiring that the user installs lots of extra programs or uses a > particular operating system. Some of the changes require the use of > GNU make, perl, gcc and GNU libc. I know for certain that there are > lots of users that do not use Linux and all (or any) of these > programs. These changes will not be included ever in WWWOFFLE.
Strange that you mention perl in the list of extra programs that are required, because you use it yourself in your Makefiles. (But I see your point, I'll change the Makefile so that it will also run if perl is missing.) I've explicitly warned people that you need GNU tools to compile the patched code. There is no such thing as absolute portability, you can only be portable to a certain degree. GNU portability is all I strive for, because I simply don't have any intention of running my code on any other system. (On the other hand, I don't want be to restricted to Linux, so if anyone detects a change that can only run on Linux, but not on another GNU system, I'd appreciate it very much if that was pointed out to me.) I don't like the way that striving for portability restricts you to a limited set of common tools. Some GNU extensions make great sense to me, and enable solutions that are (much) more elegant. And finding elegant solutions is for me one of the most rewarding aspects of coding. After all, I'm hacking WWWOFFLE to scratch my own itch; nobody is paying me to do it. I've even considered rewriting some parts of WWWOFFLE in C++, but I decided it was not worth the effort. > There are some other changes that will not be included, these include > changes to source code layout (e.g. indentation) and replacing > transparent standard C library functions with opaque wrapper macros. > Several people have commented how easy my code is to read. I think > that a standardised coding style and using standard C library > functions that all C programmers know and not too many macros helps > this. As I've mentioned to you once before, I've had experience with many programming languages but I'm a late-comer with respect to C. I'm not really a C programmer, and have no ambition of becoming one. So the functions "that all C programmers know" have no special meaning to me. In my favourite programming languages I've had some experience with, you were absolutely encouraged to write many small functions for commonly recurring operations. The main advantage of this is that you can write more abstract, compact and flexible code. The problem is that when you do this in C, there is a price to pay because each function call induces some overhead. There are two ways to avoid this: use inline functions or macros. Some of the macros I wrote could be replaced by functions. Some are butt ugly. These are valid criticisms. But I fail to see what makes char *copy=malloc(strlen(string)+1); strcpy(copy,string); so much more desirable than char *copy=strdup(string); By the way, it is because I spent time making changes of category 1 that I found errors of category 2 you mention below, so it was still useful, even if only for this reason. > 2) Some changes should be included. > > These are usually obvious to spot. Some are spelling mistakes in > source code or obvious programming errors. Anything that is obvious > in this sense should be included, the problem is finding it. I've reported some of these small errors to you in the past. The problem is that it takes time to write neat little e-mails reporting every little error separately, time that I would rather spend coding. And you don't seem particularly grateful when I do report these errors. I've searched the 127 messages written by you stored on my system for the word "thank" and I could find only two instances where you actually used it. You don't want to spend time wading through the modifications I've made (as you mention below). I can understand that. I'm afraid this is simply an example of one of the weak points of the open-source/free-software way of maintaining software. > 3) Some changes that might be included. > > The new functionality that Paul has added is obviously useful to him. > There is a risk of adding features too quickly and having a program > that is difficult to maintain and difficult for new users to > understand. Any new features that are added also potentially add new > bugs. If anybody that uses these new features thinks that they are > really great then let Paul and me know. > > Finally I will be taking the approach that Linus Torvalds takes with > patches to the Linux kernel. There is no way that I will apply a huge > patch of over 670 kB (uncompressed). There is also no way that I am > going to read through this to find the changes that fit into category > number 2 above. I never expected that my patch or any sizeable part of it would end up in the main WWWOFFLE code, this was not my reason for publishing it. The changes that I've made to the WWWOFFLE code were simply to satisfy my own personal needs. And I am pleased with the result: I find that the modified version runs much better and is much more useful than the original version. Of course there is a price to pay for using a modified version, and that is software maintenance. So I have a very selfish reason for wanting the extra features that I've introduced to end up in the main code: reduced maintenance. I've succeeded in getting a few features into the main code: the request-redirection option, the CGI-interface and unlimited number of *'s in patterns are the most important. But overall, my experience with this has been a negative one: for instance I put a lot of work into making the patch for the CGI-interface, but the way it ended up in the main code was not very useful to me. I still have to maintain the CGI-interface separately, so that I can have it the way I like it. (It was not entirely a wasted effort: the CGI-interface I ended up with is much better than it would have been if I had not collaborated with you.) For the time being I've decided that I'm not going to submit any more patches the way that I did with the CGI-interface. For now I think that the easiest way to maintain the WWWOFFLE version I'm using is to simply keep merging the modifications I've made with your WWWOFFLE updates. It's not trivial, but it's feasible. However, this does not mean that I'm no longer interested in discussing some of the things I'm doing to the WWWOFFLE code with other people. I needed to document some of the changes and make a patch file anyway, even if it was only for archiving purposes. Having done that, I might as well publish the result. If someone finds something I've done to WWWOFFLE useful, they're welcome to it. If not, c'est la vie. It was a useful exercise either way. -- Paul A. Rombouts <[EMAIL PROTECTED]> My alternative WWWOFFLE implementation page: http://www.phys.uu.nl/~rombouts/wwwoffle.html
