harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Tanzer <stru...@guglhupf.net>
Subject Re: [arch] VMCore / Component Model
Date Tue, 13 Sep 2005 17:47:43 GMT
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 guess we should continue to discuss that when the prototype is done.
Unfortunately I didn't find some time to work on it today, I'll see
what I can do until tomorrow.

> > It would be interesting to have several such proof-of-concept 
> > implementations of component models which we can study and the decide
> > which to use. We could even write "import mechanisms" for the different
> > component models so they can import and use components from another
> > model too (of course this would normally imply reduced performance).
> > 
> > Regards, David.
> > 
> > [1]
> > http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/%3c431866C9.705@gmail.com%3e
> > 
> 
-- 
David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe
http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net
My PGP Public Key: http://guglhupf.net/david/david.asc
--
Pinky, Are You Pondering What I'm Pondering?
Ewww, I think so Brain, but I think I'd rather eat the Macarena.

Mime
View raw message