Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v734)
In-Reply-To: <1127759032.2691.0.camel@Elrond.Rivendell>
References: <1126461862.16443.16.camel@Elrond.Rivendell>
 <4326FDF5.3080209@gmail.com>  <1126900048.7522.5.camel@Elrond.Rivendell>
 <1127152006.2489.14.camel@Elrond.Rivendell>
 <1127759032.2691.0.camel@Elrond.Rivendell>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <46A7604D-635B-4F84-B28A-B24E4AA61D5A@apache.org>
Content-Transfer-Encoding: 7bit
From: "Geir Magnusson Jr." <geirm@apache.org>
Subject: Re: [arch] VMCore / Component Model
Date: Mon, 26 Sep 2005 14:49:06 -0400
To: harmony-dev@incubator.apache.org

Excellent - thanks

On Sep 26, 2005, at 2:23 PM, David Tanzer wrote:

> 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/%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
> --
> Brain: Pinky, I am in considerable pain.
> Pinky: Narf! Zort! Poit! Gat! I'm with you, Brain!
>    -- Twas the Day Before Christmas
>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org