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/[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 -- AUFGABEN DER PHYSIK -- QUANTENMECHANIK Gegebene Konstante: m(Kuh)=400 kg Die Kuh befinde sich auf einer Weide, die ringsum durch einen Zaun abgegrenzt ist. Der Weidezaun sie ideal gebaut, sodass die Kuh ihn (klassich gesehen) nicht passieren kann. Begrnden Sie, dass man die Kuh trotzdem mit gewisser Wahrscheinlichkeit ausserhalb der Weide antrifft.
signature.asc
Description: This is a digitally signed message part
