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/[EMAIL > > PROTECTED] > > > -- 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 -- METHODEN DER BEWEISFHRUNG -- WISCHWEG - METHODE Man wischt die entscheidenden Stellen des Beweises sofort nach dem Anschreiben wieder weg (rechts schreiben, links wischen).
signature.asc
Description: This is a digitally signed message part
