harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Code into SVN, not the WIKI (Re: [arch] VMCore / Component Model)
Date Tue, 20 Sep 2005 06:10:57 GMT
Lets not store code in the wiki, but rather SVN.  There's no control  
on a  WIKI, so we have no clue what it is or really where it came from.

As you know, we are being very careful about code pedigree for all  
sorts of good reasons.  If you would like to get this code into SVN  
so others can start tweaking and playing, we should do that.

1) To get started, first look at the Authorized Contributor  
Questionnaire (ACQ)




and fill out a copy, print it, and sign it.  Fax to

   +1 203 665 6400

(that's my fax #).

2) Fill out an ICLA as required by part IV of the ACQ above


print it, and sign it.  Fax to same number.

Assuming that all is well with the ACQ, this means that we can accept  
the code you have put in the WIKI into SVN for people to start  
playing with.  You will have to add the code to a JIRA entry for the  
project, so you can definitively offer it under the Apache license.

Note that we are going to be testing the contribution process that we  
have thought out, so please be patient :)


On Sep 16, 2005, at 3:47 PM, 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
> --
> Man wischt die entscheidenden Stellen des Beweises sofort nach dem  
> Anschreiben
> wieder weg (rechts schreiben, links wischen).

Geir Magnusson Jr                                  +1-203-665-6437

View raw message