-------------------------------------------- kissdx Config Server support - Specification -------------------------------------------- **************************** Replacement spec follows ************************** UPDATE 2007-01-21/VT A much more user friendly way of configuring kissdx would be if the user could use a KML page instead of doing weird navigation in the pseudo- directory structure. So I think this is the way to go instead of the (now outdated) solution described below: 1. kissdx already listens for KML requests (with -k option) and forwards all requests to a specified external KML server on the net. A new config option ConfigureOnPlayer (same as below) can modify this behavior so that kissdx will put up a KML index page where the user can elect to configure kissdx or go to the external KML page. 2. kissdx will generate KML pages for the configuration dialog with the user, probably just generated internally in kissdx code, or maybe based on KML template files that reside in a "resources" directory on the kissdx server. 3. The handling of KML requests is already done in the main kissdx process. We can keep it like this, to have access to the settings directly, or we can fork a KML config process which will then have to communicate any changes back to the main process via the command port which is already in place. Forking a separate process is probably the best design decision wrt responsiveness of kissdx: We don't want the main process to be busy processing / rendering KML for long periods. **************************** Outdated spec follows ************************** RATIONALE kissdx reads its configuration from a file, kissdx.conf. This file is read on startup and is re-read when a KiSS player scans for PC-link servers. It would be even more useful if the configuration could be changed from the player's GUI without the need to edit kissdx.conf on a PC. INITIAL THOUGHTS AND NOTES A new configuration option could switch on / off the ability to edit the configuration from the player: ConfigureOnPlayer = { edit | show } A new pseudo-folder in the root menu of all three media folders (or just one) is the entry point for showing and possibly changing the configuration: [kissdx-Configuration] Selecting this pseudo-folder displays all the current configuration options with their values as pseudo-folders. Sample: [..] [audiopath = /musikk] [videopath = /video] [picturepath = /bilder] [persistentstoragepath = /opt/var/kissdx] [max_recent_files = 30] [server_character_set = CP850] [client_character_set = ISO-8859-19] etc, etc... [Use these options] [Save and use these options] Selecting one of these pseudo-folders will present a set of possible values for the selected option. Each possible value is again a pseudo-folder: [..] [max_recent_files = 30] [max_recent_files = 0] [max_recent_files = 50] [max_recent_files = 100] [max_recent_files = 200] when a pseudo-folder is selected, kissdx will present a folder listing containing a single pseudo-file with a name that confirms the selection made and a second pseudo-file giving instructions on how to proceed. These files do not exist and should not be selected. E.g. like this: [..] max_recent_files was changed to 50. Now please go back to the previous folder. Alternate approach: For a better GUI, the configuration options could be available in the Pictures root only, and the confirmation of an option change could be generated as a JPEG. This means that the listing of possible values will be a listing of pseudo JPEG files and not a list of pseudo-directories. Selecting the [Use these options] folder makes kissdx use the changed options. Selecting the [Save and use these options] folder does the same, and also persists the changed options into kissdx.conf. Not all config options can easily be set by selecting from a list, but since we cannot take input from the remote in the PC-link GUI we are limited to prepared values. We currently have these classes of options: - Number of files (max_recent_files, picturecachesize) - Path to directory on server (audiopath, videopath, picturepath, persistentstoragepath) - Path to file on server (pretrigger, posttrigger) - List of filetypes (audiofileextensions, videofileextensions, picturefileextensions, isofileextensions) - URL (kmlurl) - Filename pattern (subtitlefilemapping) - iconv character set (server_character_set, client_character_set) - TV screen width (picturetargetwidth) - TV screen height (picturetargetheight) - Percentage (picturemaxzoompercent) - Number of minutes (picturecachetrimminginterval) - Number of milliseconds (networktimeoutinterval) A usable set of prepared values can be presented for most option classes. Exceptions: The URL, List of filetypes and Filename pattern classes really need a text editor, so we can't edit those on the player. Path to directory/file could be set via directory browsing, but when the option has been set, the user must use the Back key multiple times to return to the options list (otherwise we'll get deep directory structures out of control). TV screen width and height really should be selected simultaneously from a list of common resolutions. IMPLEMENTATION CONSIDERATIONS The entire implementation should be done in a new source file, configserver.c. HERE'S A CHALLENGE: The [Use these options] and [Save and use these options] selections must communicate the changed options back to the main kissdx process for them to be used in subsequent requests from the player. Maybe we can set up a queue for IPC, or we could send a UDP request to the server like the KiSS player does when scanning for PC-link servers. SUGGESTION 1: Use pipe() to create a pipe in kissdx.c before fork'ing. See url: http://www.delorie.com/gnu/docs/glibc/libc_297.html The main process will include this file descriptor in what it waits for in its select(). Bad: This requires one pipe per subprocess, and that pipe must be added to (and later removed from) the fd_set that the main process listens to in its select(). SUGGESTION 2: Open yet another TCP port in the main kissdx.c process on startup. The main process will include this port in the ports it listens to in its select(). The port number can be dynamic and stored in a global variable that the child processes use to write to the TCP port. SUGGESTION 3: Same as SUGGESTION 2, but use AF_LOCAL instead of AF_INET so we create a local socket. Hopefully this can still be included in the select() set, making it the best solution. 2007-01-21: This method is now in use (as of v0.13-9) for toggling hidden content on/off. So we will use this method. OPTIONAL PASSWORD PROTECTION The setting of options could be protected by a password. See ToggleHiddenFilesOnPlayer-spec.txt for ideas on implementing password protection. STATUS Not implemented as of 2007-02-09.