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] > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
