harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: [arch] VMCore / Component Model
Date Tue, 20 Sep 2005 12:22:42 GMT
Have you tried to communicate between two components, one in C(++)  
and one in Java?


On Sep 19, 2005, at 1:46 PM, 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/%3c431866C9.705@gmail.com%3e
> -- 
> 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
> --
> 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.

Geir Magnusson Jr                                  +1-203-665-6437

View raw message