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.

1. 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.)
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

FHS is pretty clear:
1) the application-specific configuration files (static for the application; modify = alter the actual application,)
/etc/name-of-program/optional-name-of-module

and 2) the application-specific components (binary programs) that aren't meant to be visible

Subdir of /usr/lib for executables which are not meant to be called directly. Use /usr/libexec for non-arch-specific (script) components not meant to be called directly. Either one of these would be correct for plugin-type thingies -the specific choice based on whether it is arch-specific(binary). Of course, when I say lib I mean lib or lib64 as appropriate. /usr/libexec/<subdir> is for things like perl scripts, etc.

While many programs create their own subdir under /usr, this is 'way outta line'.

Some of the writable stuff that might go under /etc, could also be considered as being correct under /var/??? -probably /var/lib

just my two cents and according to what I understand about the FHS...
/usr/share should not be used for any writable files nor executables.

Thanks. That's some good information. I'm hoping those locations have variables for automake, but I don't think /lib/libexec has a corresponding variable. Would it be better to hard-code $(DESTDIR)$(libdir)/libexec/target, or do something else that doesn't involve that actual directory name?
ta0kira

No I meant /usr/libexec. And yes these all have autoconf names /usr/lib=libdir, /usr/libexec=libexecdir. You'll have to check on /var/lib, it's either localstatedir or sharedstatedir -It's too early for me to be certain, still lacking coffee :-).