/** WHY - a document to answer the question of "Why Anthill?" **/ /** Part of the Anthill Bug Manager distribution **/ Contents: This document specifically answers the following questions: 1. What is Anthill? 2. Why is a Bug Manager necessary? 3. What distinguishes Anthill from other Bug Managers? 4. Why WWW/Perl/MySQL/CGI::SecureState? 5. Why not ... ? 6. Closing Remarks. 1. What is Anthill? The Anthill Bug Manager is a tool that aids code development by keeping track of bugs in a multi-project, multi-developer environment. It accomplishes this with a clean, simple, and fast interface that contains all the essential features but avoids the enormous complexity associated with most other projects of this type. Anthill is intended to be a project that both helps to increase the quality of public software and serves as an official example of how to use the CGI::SecureState module on CPAN. 2. Why is a Bug Manager necessary? The chief feature that a Bug Manager includes is the ability to keep bugs under control by reminding you that they still exist. In its capacity as an official reminder, it may also include the ability to search for and categorize bugs, assign the task of fixing a bug to a certain developer, allow the public an easy an standardized way of letting developers know of a problem, or anything else that the authors decided to toss in. Most people, when they have a situation where they are not able to keep track of all of their bugs at once, are extremely happy to offload this menial task onto a Bug Manager, at the expense of a small amount of time to enter the bug in the database. In return, they usually save a large amount of time in the debugging stage of a project by not duplicating the debugging attempts of others as well as having quick access to the list of the most important bugs left on their plate. This is usually construed as a Good Thing, which has led to the widespread adoption of Bug Managers in companies of all sizes and most open source groups as well. Do not be surprised if your group experiences similar effects when using Anthill. 3. What distinguishes Anthill from other Bug Managers? Anthill was designed with the following features in mind: a) Security b) Stability c) Simplicity d) Speed and later received: e) Flexibility Elaborations: a) Security. Most people view security as something that is the opposite of usability. Let us just say that they missed the hidden cameras. Anthill was designed to assume that user input is as malicious and as dangerous as possible. In practice, Anthill takes advantage of Perl's Taint Mode, CGI::SecureState, and a rigorous authentication protocol to insure that the right people have access to the right things, and that the wrong people keep their grubby hands away. Anthill's access is strictly limited to files in its own directory and the connection to the bug database, so it can safely operate in a chrooted environment, if it is so desired. It might also comfort you to know that Anthill has had no security bugs since its inception. b) Stability. Stability and reliability are usually titles that are earned through years of hard work and thus are not normally found in new projects. Fortunately, Anthill is not a new project. It was started in the summer of 2001, and was based on the code of a Work Order Manager that has been happily serving up requests since November 2000, with exactly three bugs (all cosmetic) since its debut. Before each release, Anthill undergoes a code review and extensive testing by maddened gremlins with pitchforks. Well, at least the code review and extensive testing parts. An expert eye is also tuned toward making the code as readable and maintainable as possible, (one of the perks of using a project that is also a teaching tool for users of CGI::SecureState) which means that if a bug should happen to be found, finding and fixing should be a quick and easy process. c) Simplicity. Complexity may be a feature that is commonly associated with Bug Managers, but, in Anthill, it is abundantly absent. All the essential attributes of bugs (summary, status, priority, date submitted, extra comments, etc.) are supported, without any excess baggage. All the essential scripts are included to edit and maintain the set of bugs, projects, and developers. All that you will need is there, and no more. At least, that's what we think. If you have a different opinion, then you are free to let us know about it. d) Speed. Speed is usually obtained by removing all barriers that slow a program down. Since Anthill performs minimal processing on its own, the largest bottlenecks are database access, security measures, and template processing. Anthill uses one of the fastest known databases (MySQL), takes full advantage of mod_perl, uses one of the fastest known templating systems (XMLTemplate, which is very close to the CGI::FastTemplate module on CPAN), and does its best to make sure that the security checks kick you out as soon as possible (or let you in, if they decide that you are deserving of that privilege). As a result, Anthill simply flies, although it may seem unusual for its namesake to do so. e) Flexibility. Flexibility is a recent add-on to Anthill, and one that is still in the flowery blossom of youth. This means that you may see significant improvements in this section in the future. Flexibility came as part of Stability in that it made the code much easier on the eyes. Scripts now use templates for the vast majority of their interactions with the user so that the layout of the HTML pages produced by Anthill is separate from the actual processing done behind the scenes. The module that we use, XMLTemplate, may shortly be heading to CPAN so that Anthill may double its effectiveness as an example. In any case, it is now very easy to effect an Anthill- wide change in appearance. Additionally, in coincidence with CGI::SecureState's sudden realization that there exist non-UNIX operating systems, a large effort has been made to make Anthill "play nice" in those previously inconsequential environments. That should suffice for this answer. 4. Why WWW/Perl/MySQL/CGI::SecureState? One at a time, in reverse order: CGI::SecureState: CGI::SecureState is a module that was designed with essentially the same principles as those that appear in the answer to the previous question. Its main purpose is to hide the fact that HTTP (specifically the CGI interface) was not designed to carry session information between multiple scripts. The normal response to this problem is to use cookies and store the information on the client. However, this is neither trustworthy nor compatible with all clients (not to mention that it is not very nice!). CGI::SecureState takes the opposite path and stores the data on the server in an encrypted format, which resolves most of the difficulties associated with this process. See the CPAN for more information on this module. (http://search.cpan.org/search?dist=CGI-SecureState) It so happens that one of the authors of Anthill (Peter Behroozi) also wrote CGI::SecureState, and, since Anthill used CGI::SecureState anyway, he decided to make Anthill the official large example of how to use CGI::SecureState in a web application. MySQL: As the flexibility of Anthill increases, this may no longer require an answer. For now, however, Anthill has not been tested on non-MySQL setups, so it is necessary to explain this decision. MySQL is an immensely popular database program, due in no small part to its price (free), its license (which tends to emphasize freedom), its documentation (copious), and its speed (uninhibited). MySQL was the natural choice for this project, based on the design goals outlined in question 3. For more information about MySQL, see http://www.mysql.com/. Perl: Perl is one of the few languages that we've come across where easy things are easy, hard things are possible, and the impossible things are merely hard. It is also one of the few languages designed by a linguist, which might explain why it is possible to speak (and type) it fluently without devoting your career to learning how to do so. For more information about Perl, see http://www.perl.com/ and http://www.perl.org/. WWW: HTML is the most cross-platform "language" that we have seen except for mathematics. Since mathematics doesn't come with a nice CGI module, we felt that using HTML was the natural choice. For more information, see http://www.w3c.org/. 5. Why not ... ? To which we respond "Why Bother?" If you have a good answer, we would be most interested to hear it! 6. Closing Remarks. Anthill is a project with a very specific, if disjoint, audience. If you decide that Anthill is right for you after reading the above notes, you may feel free to try it out after reading the INSTALL file included with this package. Note: Wherever the name "Anthill" is mentioned in this document, it refers to the Anthill Bug Manager. If other projects, things, people, or fuzzy green mittens coincidentally bear the name "Anthill", it is assumed that the reader can divine from the context of this document that only the Anthill Bug Manager is being referred to. If not, that is what this note is for.