Ranges, within which changes can be made, are described in the following.

4.1.2.1 boat procedure

Since the boat procedure and the hardware recognition are Knoppix own, changes are not here necessary and/or not always possible for the VDR program. However it must be mentioned here that due to restrictions of capacity a large number at software and drivers were removed from that CD and the Kernel.
Thus the extent that reduces demo CD further to the size CD, can however exclusively for the laboratory environment be used. Therefore it would be appropriate to let with further versions the full Kernelumfang of the Knoppix version exist and to burn afterwards a DVD, in order to use so the full hardware recognition and the driver activation.

4.1.2.2 the Web surface

The Web surface is steered by the current Apacheserver. The user sees only the local web page, which is handed over by the server, after the program built dvp.py by the user inputs the sides from the HTML and XML fragments and for the pictures up.
In addition belongs the appropriate CSS file, which steers the appearance of the web page. The HTML fragments contain in each case parts to the heading, for navigation and to the Warenkorb with substitute symbols for the diagrams and left, which are then filled in each case with the XML fragments and built up depending upon Pluginauswahl.
For the XML files there is 3 different DTDs: for the Plugins themselves, for the operating module and for the controlling of the Ganzen171.
The exact flow diagram is to be inferred from the following illustration:

Illustration 22: Interaction of Apache, Python and the Menü172

4.1.2.3 the program code

The script dvp.py builds the HTML sides up for the Web surface from the individual parts, gives it back to the Web server and starts and stops the VDR. In the source text the appropriate paths at the beginning are defined.
A change is here easily and understandably possible. Python can be used both procedurally and object-oriented.
The program used here is however not object-oriented written. Therefore the source code consists of various functions, which act as follows with one another:

Illustration 23: Procedure and program calls in the Hauptprogramm173

• start (): initialize the menu, on the other functions, session management distributes the HTML inquiries
• ifaces (): determines IO haven and IRQs for the serial interface (remote maintenance)
• selection (): the list of selected Plugins, control and category opinions regulates
• auswahlisten (): The Scrolldown selection menus of the remote maintenance regulate
• patch (): The Scrolldown selection menu for the Patchs regulates
• warenkorb (): Provides the HTML code for the Warenkorb from 3 fragments
• Start (): the starting command line for the VDR builds up using the aid programmes vdrremote_server.py and modul.py
• Stop (): terminates the VDR, releases the interface of lirc again

Despite a detailed description in the Studienjahresarbeit174 result in the case of the installation of a Plugins 5 practical problems:

1. Since the file structure does not correspond to the standard defaults, the Makefiles must and the Inc. loading files to be rewritten and a new Debian package for the Plugin be provided and compiled.
2. Since the two Patchs require one installation each, thereby 2 Debian of packages for the gepatchten VDR are necessary for each Plugin.
3. For merging the Plugins into the program new diagrams for navigation, the Warenkorb and the Buttons for the entire menu must be provided, which is connected with higher expenditure despite Templates, since does not provide the pictures dynamically, but is statically loaded.
4. In addition a mindestes HTML fragment must changed or provided to each Plugin, and at least one XML fragment to be provided.
5. In addition a Plugin can to be e.g. required also auxiliary configurations, and thus additional HTML elements as a Scrollbox, or other Plugins. The problems with the integration can be improved by following theoretical changes in the program and the configuration of the Web surface.