Re: [Corelinux-develop] Library discussion

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

Ok,

So one of the fundemental issues raised are on those types that have a
need to be reason with, for example LibraryType.

A LibraryType is a member of a ontology which describes, well, types of
libraries that are applicable to the loader. 

We can accomplish in more than one way:

1. We make it a numeric identifier (1 - ?)
2. We make it name bound ("FunctionLibraryType")
3. We make it a class type (as described below)

Now I will list some of the problems with these options:

1. Numeric identifier - Hard coded numbers are not a nice thing when
considering type ontologies because there is no reasonable scheme to
describe even simple single inheritence hierarchies of types.

2. Name Bindings - These are better in that we can describe a single
inheritence hierarchy of types (LibraryType.FunctionLibrary, or
LibraryType.CORBALibrary), but they leave us stranded when/if someone
wants to describe a type with multiple inheritence properties.

3. Class Type - To me this is the optimal solution in that we can
describe any type through it's parents. It is, of course, up to those
that would use it for reasoning to traverse the RTTI information (for
lack of a Class class).

Please respond to this in the context of the current design, or if you
feel the current design is no good or missing something. If this seems
reasonable, I can move on to the discussion of the
LibraryObjectDefinitions.


"Frank V. Castellucci" wrote:
> 
> 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