corelinux-develop

[Corelinux-develop] Caution

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

In a brief ping, Christophe mentioned the KDE-2 mini-declaration idl
capability.

I would like to put a flag of caution up for a second to consider a few
things in regards to the Library Loader.

The libcorelinux (libcl++.so) should contain:

1. The mimimal framework component abstractions (currently the Library
Load design)
2. Some level of behavior that will be common across all possible domain
specializations.
3. A first level derivation of the abstraction to types for dynamic
shared function libraries, with the exception of defining actual
ExecutionObjectDefinitions.

But realize that:

The actual ExecutionObjects and respective definitions is in the
solution space of the application domain. It is up to "them" to define
what a ExecutionObjectDefinition IS, what it contains, and so on. It is
impossible for us to do that for them, after all we don't know which
libraries they will be using. Of course I will be providing an example
that leverages the framework, but I won't be needing a parser or grammar
for that.

Now, when we (CoreLinux++) publish OUR frameworks, it is extremely
likely that we will make heavy use of the Library Load mini-framework to
facilitate the component architecture. At this point, a parser for
definition interchange is a likely requirement. And IDL is clearly a
very suitable fit specifically for ExecutionObjectDefinitions, but just
as clearly useless in any other type library (images, etc.).

Thoughts? Anyone?

-- 
Frank V. Castellucci

Re: [Corelinux-develop] Caution

[Christophe Prud'h. <pru...@MI...>]

    Frank> In a brief ping, Christophe mentioned the KDE-2 mini-declaration idl capability.
a really brief one
I am very busy these days

    Frank> The actual ExecutionObjects and respective definitions is in the solution space of the
    Frank> application domain. It is up to "them" to define what a ExecutionObjectDefinition IS,
    Frank> what it contains, and so on. It is impossible for us to do that for them, after all we
    Frank> don't know which libraries they will be using. Of course I will be providing an example
    Frank> that leverages the framework, but I won't be needing a parser or grammar for that.
yes

    Frank> Now, when we (CoreLinux++) publish OUR frameworks, it is extremely likely that we will
    Frank> make heavy use of the Library Load mini-framework to facilitate the component
    Frank> architecture. At this point, a parser for definition interchange is a likely
    Frank> requirement. And IDL is clearly a very suitable fit specifically for
    Frank> ExecutionObjectDefinitions, but just as clearly useless in any other type library
    Frank> (images, etc.).
I agree on that.
I guess that you will not use the idl from CORBA but rather a smaller subset and specifically
designed for the frameworks. If so I would like to work on that.

Otherwise, IMO, the LibraryType should be a class type as you mentioned in an earlier mail.

as for the loader you specify 1..*, is it wise to be able to have multiple loader instances?
shouldn't we use the singleton pattern to ensure uniqueness of the instance and make sure that libs
are loaded once while keeping track of what is loaded?
I don't know if it makes sense or not?

regards and good night
C.

Re: [Corelinux-develop] Caution

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

Christophe Prud'homme wrote:
> 
>     Frank> In a brief ping, Christophe mentioned the KDE-2 mini-declaration idl capability.
> a really brief one
> I am very busy these days

:)

> [snip]
> 
>     Frank> Now, when we (CoreLinux++) publish OUR frameworks, it is extremely likely that we will
>     Frank> make heavy use of the Library Load mini-framework to facilitate the component
>     Frank> architecture. At this point, a parser for definition interchange is a likely
>     Frank> requirement. And IDL is clearly a very suitable fit specifically for
>     Frank> ExecutionObjectDefinitions, but just as clearly useless in any other type library
>     Frank> (images, etc.).
> I agree on that.
> I guess that you will not use the idl from CORBA but rather a smaller subset and specifically
> designed for the frameworks. If so I would like to work on that.

It may be good to consider a RDF, but we can start a thread on
frameworks as well to nail this down.

> Otherwise, IMO, the LibraryType should be a class type as you mentioned in an earlier mail.
> 
> as for the loader you specify 1..*, is it wise to be able to have multiple loader instances?
> shouldn't we use the singleton pattern to ensure uniqueness of the instance and make sure that libs
> are loaded once while keeping track of what is loaded?
> I don't know if it makes sense or not?

Actually the cardinality is 0..*, because I am allowed to have many
loaders concurrently active in the system. I might have a shared
function library loader, an image loader, a RDBMS loader, and a CORBA
loader active all at once. So the base Loader should NOT be a singleton
as it won't allow that many instantiations. 

-- 
Frank V. Castellucci