I've been developing a component-based application framework and I've gotten to the point where I'm deciding how best to implement applications built with it. A minor part of this is the actual organization of the required components on the file system.
Here is a basic summary of how applications using the framework will be created, organized, and run.
- The developer will design some sort of component interaction model for the desired operation of the application. These components might be data processors, data sources, network channels, user interfaces, etc. All will be separate processes started with executable programs (i.e. component = program.)
- All of the components in the model will interact with each other through a central node (a program from the framework) to accomplish the requirements of the application. The central node is primarily for structure and mediation, but it incidentally provides an IPC system to be used for structured bursts of executable information. This isn't the IPC; it's the framework for controlling the operations of individual components.
- The framework includes several fundamentally-useful components to add on to new applications. These include a command-line administration tool, network forwarders, and a few components for debugging.
- The developer will design custom components in C or C++ either specifically for the new application or for a package of add-ons to be used by multiple applications. These components might be database clients, hardware controllers, etc.; each performing a concise task.
- The developer will create a set of script-like configuration files for the framework-included components that will be specific to the application. These configurations will determine what components to assemble into the application, as well as component-specific things such as ports to listen to, etc. None of the included components use global (e.g. /etc) configuration files.
- Lastly, the developer creates a set of scripts to initialize, modify (a running instance,) and/or terminate the application. Generally, these scripts will be the only things known to the application's users, plus whatever additional configuration files the developer wishes to provide.
The issue I'm considering is where best to place 1) the application-specific configuration files (static for the application; modify = alter the actual application,) and 2) the application-specific components (binary programs) that aren't meant to be visible through
$PATH. Most of the component programs are inherently useless outside of the framework.
The scripts used to start the applications will generally be in a
bin directory. My thoughts as of now are to create a directory in
/usr/share for each individual application, each containing a directory for configuration files and directories for libraries and binaries.
While I'm not the "target audience" exactly, I'm the developer of the framework; therefore, I need to come up with a simple, consistent installation pattern should other developers choose to use the framework, also. Thanks.
ta0kira
PS The framework also implements IPC plug-ins, both for structured transmissions and for filtering network connections. Many of these might be specific to an application and therefore shouldn't clutter up the
lib directories.