|
From: Frank V. C. <fr...@co...> - 2000-08-13 02:15:36
|
Christophe Prud'homme wrote:
> [snip for irrelevance now that there is a quorum]
> >
> > What I'm getting at is I think that the IMPLEMENTATION of frameworks, in
> > this case the FunctionalLibrary loader et.al. are probably really an
> > example of the CoreLinux++ frameworks that are one of the goals of the
> > project.
> >
> > Anyone?
> so what you say is that it is time to putthings into libframeworks?
> if so why not!
> in fact it is quite good to think that core(linux) really means it (that it
> is a core library): that is to say that it doesn't extra libs
>
> -ldl is not such a requirement but keeping corelinux as a standalone lib(a
> part the c++ lib of course) is very good since dl features are needed only
> for a one corelinux feature
>
> My preference would be to not add -ldl as a requirement and so begin to
> populate corelinux++ frameworks
Yes!
So it is reasonable for me to move the Library Load abstraction into a
framework itself, oui?
What we should now consider is organization of frameworks. I think
something like :
Until we come up with a Framework management framework (something to
discuss later), each of the sub-frameworks (Library Load, Persistence,
etc.) should exists as semi-independent libraries.
Maybe something along the lines of a java package metaphor. So:
where LibLoad = LibraryLoad (for example)
Main
====
clfrmwrk (vacous root)
clfrmwrk/LibLoad
clfrmwrk/LibLoad/admin
clfrmwrk/LibLoad/{etc}
Headers
=======
clfrmwrk/LibLoad/LibLoad
Sources
=======
clfrmwrk/LibLoad/src
clfrmwrk/LibLoad/src/LibLoad
clfrmwrk/LibLoad/src/FuncLibLoad (etc for each library load type)
The key here is that we need the ability to release different versions
of different frameworks independent (with restrictions on later
dependencies) of each other.
Of course, your mastery on packaging will mean maybe using the root
(clfrmwrk) to automate that?
What do you think?
--
Frank V. Castellucci
|