harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: [vote] Accept JIRA contribution HARMONY-5 : David Tanzer's proof-of-concept component model
Date Fri, 30 Sep 2005 13:33:27 GMT
Guys!  It's for the sandbox!

No one is going to reject contributions to the sandbox except for  
reasons of code provenance - i.e. "Hey, that's Sun's source!"  - or  
complete misalignment with project, such as someone donating an EJB  
container or something.

Further down the road, when we are at work on our "complete platform"  
for J2SE, rejecting the inclusion of code _from_ the sandbox _into_  
the main platform is reasonable, and I personally can't wait until we  
are that far along that we can have those discussions :)

geir

On Sep 30, 2005, at 8:41 AM, acoliver@apache.org wrote:

> 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/%3c43326A25.40409@anu.edu.au%3e
>> [2]
>> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/ 
>> 200508.mbox/%3c4dd1f3f0050827071543279cac@mail.gmail.com%3e
>>
>>> 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.
>
>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org



Mime
View raw message