[Corelinux-develop] Library discussion

[Frank V. C. <fr...@co...>]

Christophe brought up a question about the Library Loader framework
implementation.

It may be useful to read this along side the design diagram

For the purposes of our discussion:

Library - This is really a registration point for users (developers) to
register (at run time) a loader. To register a loader you need two (2)
things: A Loader instance, and a LibraryType instance. Assuming there is
no conflict, the Library now has a Loader service which can begin work.
When a user calls the Library to create a LibraryInstance, they must
include two things, the name of the library, and the type of loader that
should handle the actual loading. At this point, a LibraryInstance is
given back to the caller.

Loader - Besides the physical resolution and loading of a library, the
Loader is a factory for LibraryInstances.

LibraryInstance - is the in memory object that represents, for all
intents and purposes the library that was loaded. The responsibility for
the LibraryInstance is to create, upon request, a LibraryObject. The
LibraryInstance interacts with a ObjectDefinitionRegistry to determine,
at run time, which type of LibraryObject derivation to instantiate. This
is done by the caller registering a series of LibraryObjectDefinitions
that describe what LibraryObject derivation should be instantiated upon
request. This works by using the key from the LibraryInstance as
associating LibraryObjectDefinitions to it.

ObjectDefinitionRegistry - an manager of the associations between a
library and the LibraryObjectDefinitions that it contains. 

LibraryObjectDefinition - a prototype which describes the interface and
behavior of the actual LibraryObject instance. These are a sort of Class
class, or meta-model which can be reasoned with at run time.

LibraryObject - is what the client actually interacts with to do
whatever work with the object that the library type has described. 

---- end

Because it is a framework, it is required that the developer extend a
number of the components to work together. We will actually be
implementing the first extension which will handle loading dynamic
shared libraries whose functions have a C calling convention. To do
this, we will provide:

FunctionLibraryType (LibraryType) - fairly vacuous type derivation.
FunctionLibraryLoader (Loader) - utilizes dlopen and dlclose to open
libraries.
FunctionLibrary (LibraryInstance) - exposes interface for getting and
returning ExecutionObjects.
ExecutionObjectDefinitions (LibraryObjectDefinition) - used to describe
ExecutionObjects
ExecutionObject (LibraryObject) - exposes the ability to "execute" with
arguments and return values.

What the user will be responsible for to utilize the FunctionLibrary
series is to create whatever ExecutionObjectDefinitions are needed at
run time to serve up useable objects.

Now, this is a big "small" step for CoreLinux++ in that we are getting
more into a framework type component, than the general patterns or IPC
objects to date. There is a few issues that need to be cleared up as
well, for example, like "HOW" do we describe arguments and return
semantics? I have done this before but in a big way, maybe there is a
better way.

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package