This library is intended to be used whenever one wants to build an application capable of using external pieces of code, loaded at runtime, to implmement features which were unkown/unplanned at design/implementation time. If you are familiar with the concept of "plugin", hereby called module, then that's the same exact thing.

Furthermore, it is designed from the ground up to allow peaceful coexistence and cooperation among different classes of modules, each handled by a modular subsystem (a collection of functions and resources for manipulating a specific class of modules).

So we have one unified API trying to accomodate three different needs: application development, modular subsystem development and module development.

From this library's point of view, there's absolutely no distinction beetween NASPRO core-based libraries and applications, so we just call them hosts from now on (in case we need a distiction we say host library or host application).

In the end, we can say that the most obvious purpose of this library is to handle the structural interactions beetween hosts and modules (loading, unloading, symbol retrieving).

Modules

The concept of module in NASPRO is generalization of the usual concept of plugin.

The most evident difference is that a NASPRO core host can load modules made of "bundles" of code and data (much like LV2 plugins), either grouped in directories or not, as well as using the classic approach of having modules made of only one shared object file.

Then, having a unified API for the infrastructure of hosts and modules, makes it possible to reach high levels of integration between the two. For example, module developers can easily notify hosts on what's happening just using the same message reporting feature offered to the hosts themselves. Or even, modules can turn into hosts and load other modues (this approach is going to be used widely in the rest of the framework).

Anyway all of these things are just optional; the NASPRO core library will be able to efficiently handle regular modules as well.

Modular subsystems

A modular subsystem is exactly what the name suggests: a set of rules and functions to use modules of a particular kind. Hosts can define one or more modular subsystems.

Hosts

As said, this library makes no difference between host libraries and host applications, and the development of one or the other shows no particular difficulty at all (given a good understanding of how it works). Of course, neither it does force developers to follow the conventions and the mechanisms it uses (all are easily wrappable).

The only remarkable distinction between libraries and applications to be considered is the fact that library code has to be reused, obviously. So, in order to prevent code clashes in some particular circumstances, each host should have a 23 bits wide host id associated with it.

Host application developers shouldn't actually care about it, since a value is always reserved for the application. For host libraries, instead, an id reservation/registration service is going to be set up by this project.

Anyway, as better explained later on, 10 ids are always reserved for development, so that programmers can randomly choose one of such values and use it before asking for id reservation.

On the functional side, the NASPRO core library will offer a set of facilities for fine-grained control, like, for example, the possibility to associate a set of memory management functions and callbacks for message reporting to each host, and use these resources instead of its own when handling data for them.