On Tue, 2005-09-13 at 17:27 +0100, Tim Ellison wrote: > [Snip] > > 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. [Snip] > I look forward to seeing the proof of concept. Were you thinking of > introducing versioning and dependency management style functions?
I was thinking about a really simple model, basically only a framework which loads shared libraries and creates the function pointer tables you described in your posting. Versioning and dependency management will be a requirement, but I didn't consider it so far in my proof-of-concept (which will take a few more days to finish), and the libraries which are loaded should be configurable. I also think we should be careful not to introduce too much runtime costs, and I'm implementing my prototype under the assumption that we don't need to manage arbitrary components (so I assume that the component interfaces and dependencies are known at compile time). Anyway it would be possible to extend my approach for arbitrary (i.e. unknown) components. I guess we should continue to discuss that when the prototype is done. Unfortunately I didn't find some time to work on it today, I'll see what I can do until tomorrow. > > 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 -- Pinky, Are You Pondering What I'm Pondering? Ewww, I think so Brain, but I think I'd rather eat the Macarena.
signature.asc
Description: This is a digitally signed message part
