On Sep 13, 2005, at 1:47 PM, David Tanzer wrote:
On Tue, 2005-09-13 at 17:27 +0100, Tim Ellison wrote:
[Snip]
I guess a requirement for such a component manager would be that
it can
load and connect components at runtime and that the specific
implementations which are loaded can be configured. It might also be
good if the same component implementations can be linked at
compile time
(i.e. statically) which could have benefits on embedded
platforms, but
I'm not sure if we really need this.
I'm assuming that you are speculating on component management
beyond the
platform support (i.e. DLL-hell). The java world is already on
this path
with the OSGi framework (e.g. Felix). It will require a non-trivial
solution to ensure that the runtime flexibility does not incur an
unacceptable runtime cost.
[Snip]
I look forward to seeing the proof of concept. Were you thinking of
introducing versioning and dependency management style functions?
I was thinking about a really simple model, basically only a framework
which loads shared libraries and creates the function pointer
tables you
described in your posting. Versioning and dependency management
will be
a requirement, but I didn't consider it so far in my proof-of-concept
(which will take a few more days to finish), and the libraries which
are loaded should be configurable.
I also think we should be careful not to introduce too much runtime
costs, and I'm implementing my prototype under the assumption that we
don't need to manage arbitrary components (so I assume that the
component interfaces and dependencies are known at compile time).
Anyway it would be possible to extend my approach for arbitrary (i.e.
unknown) components.
I think that ultimately, this will be necessary. I imagine we want
to be able to allow others to plug in new components easily.
geir
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
