Hi guys,

Well after looking into KIO and the way that you guys are doing things with klik, it seems that an IO Slave might be of limited utility (although I admit I'm not really really experienced with all of the uses of KIO). All it would really do it download the klik recipie to the local system and run it to create your cmg file. Once you have the cmg file there are more uses for it, like installing local files, icons, menu entries, etc. What would probably be more useful is a service that listens to a directory like ~/.applications and /opt/share/applications or /usr/local/applications and installs/uninstalls those things automatically when as file is added to or removed from that directory. Then you wouldn't need an IO slave at all. However, this would require a descritpion file to be installed in the cmg file to tell the daemon what files to install and uninstall to the local system when the program is installed or uninstalled to one of those special directories.

However, it seems that some recipies are not without their problems. For some reason some programs don't work properly. e.g. ksirc doesn't save my preferences or anything. I think that the IO Slave is of much more utility if a recipe is *not* a shell script, but a series of MACRO actions that are interpreted into actual actions on the file system by the daemon. These MACRO's could be defined by plugins to the daemon (service) and be written in shell, perl, python, c, c++ etc. I could probably use the plugin and MACRO code from lineakd to do this but it's a pretty large undertaking, it involves completely standardizing, codifying and reingineering the klik system. However, then each distribution can write macros that are specific to them and you don't have to put platform specific code into the the recipie.

Sheldon.