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 Fri, 16 Sep 2005 19:47:28 GMT
Ok, it took a little bit longer than I first expected, but now my 
proof-of-concept implementation of the component model I described is
available in the wiki:
I have also linked it from the harmony architecture page.

It contains a mechanism for loading components and a basic versioning 
and dependency management mechanism. The test case loads two components,
where one depends on the other. I'll add some more explanations to the
wiki page when I have more time, hopefully at the weekend.

I have made several assumptions about the directory structure, the 
coding conventions and the documentation conventions, we should maybe
discuss this in a different thread.

Regards, David.

On Tue, 2005-09-13 at 17:27 +0100, Tim Ellison wrote:
> David Tanzer wrote:
> > Since we already started to define some component interfaces I think we
> > also should start thinking about a component model which loads / 
> > connects such components. Maybe there are also some existing solutions
> > we might want to look at (I must confess I didn't really search yet).
> Agreed, plus managing the API itself to ensure forwards/backwards
> version compatibility.
> > 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.
> > Another requirement would be that the components can be written in 
> > different programming languages (i.e. C, C++, Java, ...). It isn't 
> > really a problem to solve this for C and C++, but can we also easily
> > support other programming languages?
> > 
> > A simple way to implement such a component model in C would be an 
> > approach similar to the one Tim Ellison described in [1] where he
> > explains the structure of the J9 VM's portability library. I started
> > writing a proof of concept implementation for this, and I'll add it
> > to the wiki as soon as it's finished.
> I look forward to seeing the proof of concept.  Were you thinking of
> introducing versioning and dependency management style functions?
> > 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
Man wischt die entscheidenden Stellen des Beweises sofort nach dem Anschreiben
wieder weg (rechts schreiben, links wischen).

View raw message