Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Mime-Version: 1.0 (Apple Message framework v734)
In-Reply-To: <1126633663.2487.9.camel@Elrond.Rivendell>
References: <1126461862.16443.16.camel@Elrond.Rivendell>
 <4326FDF5.3080209@gmail.com> <1126633663.2487.9.camel@Elrond.Rivendell>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <B2BCA16F-845D-4DB7-AFCF-EB390CE74E58@apache.org>
Content-Transfer-Encoding: 7bit
From: "Geir Magnusson Jr." <geirm@apache.org>
Subject: Re: [arch] VMCore / Component Model
Date: Tue, 20 Sep 2005 08:21:25 -0400
To: harmony-dev@incubator.apache.org


On Sep 13, 2005, at 1:47 PM, David Tanzer wrote:

> 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 think that ultimately, this will be necessary.  I imagine we want  
to be able to allow others to plug in new components easily.

geir

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