harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Tanzer <stru...@guglhupf.net>
Subject Re: [arch] VMCore / Component Model
Date Tue, 20 Sep 2005 14:06:44 GMT
Geir Magnusson Jr. wrote:
> Have you tried to communicate between two components, one in C(++)  and 
> one in Java?

No, I didn't try that yet. For native compiled java code (gjc) I guess
it should be straight forward to extend my proof-of-concept to support
it.
For java code which runs in the harmony vm the interface will have to
be different, but we need this interface too.

> geir
> 
> 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
>> -- 
>> 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.
>>
> 


Mime
View raw message