Have you tried to communicate between two components, one in C(++)
and one in Java?
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/[EMAIL PROTECTED]
--
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.
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
