Oh gosh, it is way too early to reject things for such reasons. Instead
of being a roadblock, contribute patches. That is the affirmative thing
to do rather than starting out with the hammer. It is really hard to
start a project in the fashion of harmony (w/o initial codebase) because
so many initial decisions in any project must favor "the least thing
that could possibly work" -- beyond this you take into concern "other
things".
For instance, I'm quite interested in a VM that sucks less than IBM's
for the AIX P5 platform, but I'm not going to "-1 this won't work on
AIX". I guarantee no code submitted will be perfect and some won't even
be immediately portable especially in the early stages. PLLLLEEEAAASE
take an affirmative view rather than a "code by committee" negative view.
-Andy
David Tanzer wrote:
On Fri, 2005-09-30 at 02:58 -0400, Geir Magnusson Jr. wrote:
On Sep 30, 2005, at 2:51 AM, Mladen Turk wrote:
Geir Magnusson Jr. wrote:
David Tanzer has offered his proof-of-concept component model to
the project. It can be found here :
http://issues.apache.org/jira/browse/HARMONY-5
[ ] +1 Accept the code into the project
[X] -1 Don't accept the code. Reason :
The code itself is posix only.
It's a proof of concept for the sandbox! This isn't a commitment to
the idea or the implementation, but just getting it in so people can
play....
Right, that's what my intention was, nothing more.
If we continue this way, porting to the other platforms will
become impossible.
Even the simple posix itself is incompatible between various
flavors. For example on AIX there is 'archive.a(dso.so)' and
dlopen needs 'RTLD_NOW | RTLD_GLOBAL | RTDL_MEMBER' flags.
Some platforms like HPUX use the shl_load, not to mention the
Windows or Netware.
The actual code itself exists, and is very much mature within
Apache2, and module dependencies are implemented within apr-iconv
project, so perhaps this would be a way to go.
APR? I think that we'll leverage APR heavily. Whether or not the
APR API is the one we use as the standard porting layer API remains
to be seen. If not, I'm certain will used it for platform
implementations of the porting layer...
There are several places in the code where I've added comments about
things that have to be changed if we really use this component model.
Note that there are also serious concerns about performance in a
runtime-configurable component model and Robin Garner suggested to aim
for compile time configurability (See [1]). APR would definitely be a
better choice than posix, but AFAICS the decision about what our
portability layer will be has not been made yet.
Also, what about coding style guide?
That's a good question, and something I assume we'll converge around
as we get moving.
I totally agree with that. I discussed earlier with Weldon Washburn
and Geir about using the Java Coding Conventions where possible (See
[2] and follow-ups), but this still doesn't cover things like directory
structure, some aspects of documentation policy, etc., and there was no
decision yet.
Regards,
David.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL
PROTECTED]
[2]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL
PROTECTED]
geir
Regards,
Mladen.
--
Andrew C. Oliver
SuperLink Software, Inc.
Java to Excel using POI
http://www.superlinksoftware.com/services/poi
Commercial support including features added/implemented, bugs fixed.
