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
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 class
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 funct
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.
H
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 bring
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
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 harmon
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. Otherwise I might suggest a segment of the willing go
off and
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 talking
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 see
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?
> Assuming that all is well with the ACQ, this means that we can accept
> the code you ha
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 ins
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 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 config
Hi,
sorry if this is a bit long, my fault for not catching up with the list
for a few days ;-}>
headlines are:
* Cross-platform and language support
- ltdl vs dlfcn
- native code needed to access native code, jikes boot strap system
- Java based loader?
* In-lining of code
- let the JIT
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
a
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
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 s
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
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
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 mech
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
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 searc
23 matches
Mail list logo