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)
Subject: Re: [arch] VMCore / Component Model
From: David Tanzer <struppi@guglhupf.net>
To: harmony-dev@incubator.apache.org
In-Reply-To: <4326FDF5.3080209@gmail.com>
References: <1126461862.16443.16.camel@Elrond.Rivendell>
	 <4326FDF5.3080209@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature"; boundary="=-ydKm6fE2RLCdumJcfoqX"
Date: Fri, 16 Sep 2005 21:47:28 +0200
Message-Id: <1126900048.7522.5.camel@Elrond.Rivendell>
Mime-Version: 1.0

--=-ydKm6fE2RLCdumJcfoqX
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Ok, it took a little bit longer than I first expected, but now my=20
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=20
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=20
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 /=20
> > 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).
>=20
> Agreed, plus managing the API itself to ensure forwards/backwards
> version compatibility.
>=20
> > I guess a requirement for such a component manager would be that it can
> > load and connect components at runtime and that the specific=20
> > implementations which are loaded can be configured. It might also be
> > good if the same component implementations can be linked at compile tim=
e
> > (i.e. statically) which could have benefits on embedded platforms, but
> > I'm not sure if we really need this.
>=20
> 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.
>=20
> > Another requirement would be that the components can be written in=20
> > different programming languages (i.e. C, C++, Java, ...). It isn't=20
> > really a problem to solve this for C and C++, but can we also easily
> > support other programming languages?
> >=20
> > A simple way to implement such a component model in C would be an=20
> > 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.
>=20
> I look forward to seeing the proof of concept.  Were you thinking of
> introducing versioning and dependency management style functions?
>=20
> > It would be interesting to have several such proof-of-concept=20
> > 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).
> >=20
> > Regards, David.
> >=20
> > [1]
> > http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.m=
box/%3c431866C9.705@gmail.com%3e
> >=20
>=20
--=20
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
--
METHODEN DER BEWEISFHRUNG -- WISCHWEG - METHODE
Man wischt die entscheidenden Stellen des Beweises sofort nach dem Anschrei=
ben
wieder weg (rechts schreiben, links wischen).

--=-ydKm6fE2RLCdumJcfoqX
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBDKyFQMfZBqDjGEm4RApXeAJ4gbTGj2B3UqTD1gaCS0YSQITbg6QCcDlJZ
aKL0hFMMKXUmf8EWaGcr8EA=
=Lc3w
-----END PGP SIGNATURE-----

--=-ydKm6fE2RLCdumJcfoqX--