NetLoony Introduction

 • What is NetLoony?
 • Why develop it?
 • Why not help an existing GUI project?
 • Why the Java application approach?
 • What is planned for the future?

• What is NetLoony?

NetLoony is a Graphical User Interface (GUI) for the Apache HTTP Server which makes learning, configuring and controlling the Apache HTTP server much easier. Written in 100% Java, it is a platform independent application.

It is much more than a straight forward GUI, as it comes with a performance monitoring tool, user and group access configuration tool, transaction logging, online-updates.... Also, we are already developing security analysis tools, compilation tool, as well as continuously extending the point and click configuration capabilities. We will also be supporting more third party modules; these will be distributed as updates when available.

• Why develop it?

There is a demand for an Apache GUI, which has been met by a few freeware and commercial efforts - But we noticed there wasn't one which was at a realistic price (or free) and was capable of supporting all (or a majority) of the Apache commands, plus third party modules.

We decided to start developing an Apache GUI for our own use, and it is only in the last few months, after increasing demand, have we decided to commercially release and support our GUI - NetLoony. By this time, it had developed into a very sophisticated application.

The Apache HTTP server is totally free, so we didn't want contradict the Apache philosophy by releasing a totally commercial compliment application. At the same time, we could not allocate resources for ongoing development and support without any financial return.

A fair solution was to have both a commercial and non-commercial license, whilst having no distribution restriction. Commercial users are expected to pay a license fee which will also include 12 months support and application updates. Non-commercial use is totally free, but without the support and updates.

• Why not help an existing GUI project?
  1. This was an option, but we didn't see any projects which were approached as we would like. It was an easier option to start the project from scratch, rather than go through a large change process. We wanted a project that used Java and included a direct interaction with Apache HTML documentation to help learn Apache command configurations.

  2. We also wanted to provide a service to support our application, which is usually outside the scope of open-source projects. This is not saying that open-source project don't have an element of support, some do very successfully via docs, newsgroups, patches and email. But we haven't seen this implemented as a strict part of the project specification.

• Why the Java application approach?
With a project like this, you are not short of methods or languages.

  • The most popular approach would be CGI scripts which allow the font-end to be easily and comfortably designed with HTML. The administration of the server can also be performed from anywhere via the Internet/Intranet. Also, scripting languages like Python and Perl have been ported to several platforms and the initial download size is likely to be quite small as scripts compress easily.

    But, there are limitations when using an HTML front-end unless enhanced with JavaScript and Java Applets. Another issue is response times can be a little slow with using Applets or constant send/response updating. Also, if the server is down for some reason, the Apache configuration scripts will still have to be accessed manually (which is how it is currently done).

  • Another method would be to create an application using a platform portable scripting language. TK/TCL and Java would be popular choices for this, file sizes are likely to be very small; therefore allowing quick download times.

    But, applications like this can run up to 20 times slower than native (machine code) applications; this is the pay-back for using platform independent languages.

  • The Java application method was adopted because of the following:

    1. The vast amount of development and support for Java, continually increasing its capabilities and speed.

    2. The lack of speed is becoming less of a problem has it noticeably increases with higher processor speeds (which is continuous). We also feel that speed and usability relies on design just as much as the programming languages, platforms and processors. Note: We test this application on processors as low as 133Mhz (non-MMX) and 16MB of RAM.

    3. Java is supported by a wider range of platforms than other scripting languages.

    4. Java compresses down into very small components, therefore very short downloading times.

    5. An application would be easier to install and set-up rather than CGI scripts (for this type of application).

    6. The graphical interfacing components of Java are far more advanced than any other scripting language.

    7. The application method does not rely on a running Apache server and network to configure Apache.

    8. Because Java has powerful networking capabilities, remote configuration will be possible to implement.

  • • What is planned for the future?
    The objective of our application and service is to make configuring Apache an easy and approachable task, as well as allowing access to Apache's full configuration capabilities, for both the novice and expert. That is, and always will be, the objective of this application.

    We plan to provide further tools to help the management your Apache controlled web site, as well as the configuration aspect. These management tools will analyse security, performance, in fact everything to take the guess work out of configuring Apache.

    The future for NetLoony is really up to you, the user, to define, just as much as it is up to us. So, got any good ideas?

    NetLoony Introduction