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 Mon, 26 Sep 2005 18:23:52 GMT
I have now added the prototype implementation to JIRA:

http://issues.apache.org/jira/browse/HARMONY-5

Cheers,
David.

On Mon, 2005-09-19 at 19:46 +0200, David Tanzer wrote:
> Today I have added some additional Information to the Wiki page.
> 
> We should also consider using C++ and abstract classes to maintain our 
> component model. While this would make inter-component communication
> slightly slower it would be easier to maintain. We should also think
> about using an existing component model like OSGi.
> 
> The model I posted provides pretty fast communication between components
> without sacrificing too much flexibility, but it is maybe not as easy to
> maintain as a clean, object-oriented implementation (i.e. C++). We could
> discuss how important these aspects are to us, i.e. how much runtime
> efficiency we are willing to sacrifice for maintainability and 
> flexibility and vice-versa.
> 
> Regards, David.
> 
> On Fri, 2005-09-16 at 21:47 +0200, David Tanzer wrote:
> > 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:
> > http://wiki.apache.org/harmony/ComponentModelFunctionPointers
> > 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
--
Brain: Pinky, I am in considerable pain.
Pinky: Narf! Zort! Poit! Gat! I'm with you, Brain!
   -- Twas the Day Before Christmas

Mime
View raw message