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/[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 -- Brain: Pinky, I am in considerable pain. Pinky: Narf! Zort! Poit! Gat! I'm with you, Brain! -- Twas the Day Before Christmas
signature.asc
Description: This is a digitally signed message part
