|
From: Frank V. C. <fr...@co...> - 2000-07-30 23:38:35
|
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 |