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
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
On Tue, 2005-09-20 at 08:40 -0400, Geir Magnusson Jr. wrote:
On Sep 20, 2005, at 12:26 AM, Robin Garner wrote:
I think it's important not to take Tim's point about performance too
lightly here. There are some key interfaces between components that
can't afford the overhead of a
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
Geir Magnusson Jr. wrote:
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.
I totally agree with that, I just didn't know if I have SVN write access
and how we structure the repository. I guess it would
On Sep 20, 2005, at 3:07 AM, David Tanzer wrote:
Geir Magnusson Jr. wrote:
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.
I totally agree with that, I just didn't know if I have SVN write
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
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.
On Sep 20, 2005, at 12:26 AM, Robin Garner wrote:
I think it's important not to take Tim's point about performance too
lightly here. There are some key interfaces between components that
can't afford the overhead of a function call, let alone an indirect
call via a function pointer.
Three
Peter Edworthy wrote:
[Snip]
First of all thanks to David Tanzer, having something solid to start from
makes a tremendous difference. The code captures a basic functional spec
for a component loader very well.
I'm not very familiar with UNIX dynamic libs so if this is way off please
say;
It
On Sep 20, 2005, at 9:11 AM, Davanum Srinivas wrote:
Geir,
When folks have sent in their ACQ/ICLA, we should give them direct
commit access (after maybe a VOTE on the ppmc list). I really don't
like putting so many road blocks, what exactly are we waiting for?
What roadblocks are you
Geir Magnusson Jr. wrote:
Have you tried to communicate between two components, one in C(++) and
one in Java?
No, I didn't try that yet. For native compiled java code (gjc) I guess
it should be straight forward to extend my proof-of-concept to support
it.
For java code which runs in the
So let's do it then...Everyone interested should fill in their
paperwork by end of the month. First week next month we can have a
VOTE on the PPMC for each person based on their contributions so far.
(Let each person state what they are bringing to the table as well if
they haven't already). So by
On Sep 20, 2005, at 9:36 AM, Davanum Srinivas wrote:
So let's do it then...Everyone interested should fill in their
paperwork by end of the month. First week next month we can have a
VOTE on the PPMC for each person based on their contributions so far.
(Let each person state what they are
On Sep 20, 2005, at 9:29 AM, [EMAIL PROTECTED] wrote:
Dude,
It's catch 22. There weren't any legitimate committers (because
there was no initial code base) at the beginning of the project to
vote. Because of this, there needs to be a lower barrier of entry
than a formal procedure.
I think it's important not to take Tim's point about performance too
lightly here. There are some key interfaces between components that
can't afford the overhead of a function call, let alone an indirect
call via a function pointer.
Three instances that come to mind are:
- Allocation. For best
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
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
18 matches
Mail list logo
