Elego ComPact is designed as a set of tools which can either be used from the command line or integrated into scripts and makefiles, or accessed through a graphical user interface. The separation of the main functionality from the user interface allows for a great amount of flexibility.
This flexibility is further increased by the use of a specialized HTTP server and a standard WWW browser for the realization of the graphical interface. All graphical rendering and layouting is performed by the browser, while the server generates appropriate HTML pages that contain the needed information and interaction controls.
The WWW server ComPactHTTPd interprets some special URL syntax to initiate external program calls, cache flushes etc., and also contains an interpreter for a small scripting language ExHTML, which is used to generate state dependend and iterating HTML constructs.
The basic concept of HTTP-based WWW systems is that a server process maintains a set of documents (text, graphic, sound etc.) that it issues upon requests made for these documents which are denoted by URLs (universal resource locators). An URL usually consists of a method to deliver the document (in our case always http:), the address of the server process (for example //localhost:7777) and a pathname which uniquely identifies a certain document (for example /index.htm), followed optionally by a list of arguments that might change the document in case it is dynamically generated or modified. Documents may be of different types known to the server, which may be processed in special ways before they are sent in answer to a request.
A WWW browser acts as client for a WWW system and is used to display structured documents, usually including text, graphics, sound, animation, and links to other documents. All layouting and rendering of documents is done by the browser. The user interacts with the browser via a pointer device (usually a mouse) and a keyboard for alphanumerical input. Links in the document are followed by activating them with a mouse click, which instructs the browser to send a new request to a server, which in turn locates the requested document, performs any special processing required by its type and the arguments of the request, and sends the document back to the browser, which then displays the results in (part of) a window.
The current graphical user interface of ComPact makes use of frames, which are hierarchically structured divisions of the display window of a WWW browser, and dynamically expanded HTML pages that include algorithmic elements written in ExHTML. The ComPactHTTPd server includes an interpreter for the execution of ExHTML statements, which in turn are used to perform all the configuration management and general functions implemented by the GUI.
Alle frames in the ComPact GUI are named and may be the target of an HTTP request. One of the major drawbacks of using HTTP for the implementation of a GUI is the fact that each HTTP request has exactly one answer which is targeted at (i.e. displayed in) one frame or window of the browser. This model is in general too simple to realize the complex event-driven actions of traditional graphical user interfaces. There are two possible workarounds for this problem: to require the execution of some algorithms on the client side (e.g. by using JavaScript) or by targeting the answer at a set of frames. The last one is only possible if it fits into the hierarchical structure of the frames, and is furthermore in general somewhat inefficient, as the complete frame set needs to be recalculated and redisplayed (which usually includes lots of unneeded actions).
The use of script languages like JavaScript has been avoided, as it is currently not very portable across different browsers. Several different versions of specifications of JavaScript exist, and every browser (and browser version) implements its own language dialect, so that the ComPact GUI makes very rare use of this feature.
Frame sets are used as targets whereever possible to solve the described event distribution problem; but in some cases the costs were too high or this solution was not applicable at all. So in general the ComPact GUI is based on the principle that certain information displayed in frames is updated on demand, i.e. an explicit reload of the frame (which can usually be effected easily by use of the context button of the mouse). This is especially true for two situations:
if the target of a request is the Execute Window, which is used to display the results of an external program execution, which in turn may of course change the status of several elements displayed currently in other windows, and
if the time for recomputing the requested information is so long (for example the display of the complete version control status of a project) that it seems inappropriate to initiate this action at every small change.
It may even be necessary to issue an update request that flushes or reloads several caches used by the ComPactHTTPd for efficiency reasons. You should also bear in mind that some of the information displayed is valid only at the time it was computed (i.e. the up-to-date status of a package or a package element), as others may commit changes to the repository at any time, and a perpetual scanning of the repository would be very inefficient. Future versions of Elego ComPact will mitigate this problem by inclusion of a special event distribution service which is used by all ComPact tools (but which will nonetheless also take its time and probably be somewhat unreliable when used in today's wide area networks). Until then the display of really up-to-date information will sometimes require some user interaction.