Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v730)
In-Reply-To: <83094C9C-ED92-45F4-B459-9F5D42E91433@trifork.com>
References: <42C8FC62.4030503@trifork.com>
 <20E78FB0-20DE-48BC-A894-DCCA2F9E43BD@apache.org>
 <83094C9C-ED92-45F4-B459-9F5D42E91433@trifork.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <027D9325-DD87-4B2B-833F-0A47B5372FEA@apache.org>
Content-Transfer-Encoding: 7bit
From: "Geir Magnusson Jr." <geirm@apache.org>
Subject: Re: Donation of a CORBA Orb
Date: Wed, 6 Jul 2005 12:10:15 -0400
To: dev@geronimo.apache.org


On Jul 4, 2005, at 11:53 AM, Kresten Krab Thorup wrote:

> Geir,
>
> Thanks for your questions, as I was trying to answer the response  
> ended up becoming rather lengthy...
>
> First off, I don't think that it makes too much sense to just toss  
> a bunch of code over the fence; that would be a dead-end.  We need  
> to set it up such that it becomes part of the community, and to do  
> this I am thinking that it would be good to engage the community in  
> rewriting some parts of the ORB that we were thinking to refactor  
> anyway. If we piecemeal the contribution in smaller chunks I am  
> thinking there is a better chance to make it everybody's property.   
> As for schedule of this, we're thinking that it would come in  
> pieces over the next 4 months or so.  We need to do some clean-up  
> and partitioning from the rest of our code base and as I said  
> before, we would like to introduce this whole thing gently both to  
> us and the community.

Great - I assume this means that your internal timeline is 4 months  
to contribute the entire ORB?

>
> I think of this as a sing-along or "karaoke" project: somewhere in  
> between "writing from scratch" and "donation".  We will take the  
> individual parts of the Trifork ORB, clean them up with coding  
> standards, javadoc, etc.; and have the community be part of  
> reworking and improving the pieces along the way.  For some parts,  
> such as the core io, I would like it to be redone entirely; whereas  
> much of the higher-level logic such as RMI/IIOP and POA handling  
> can go almost straight through.  When we're all the way though the  
> entire code base will be appropriately "apachified."
>
> As for where it should be placed ASF-wise, I am thinking that it  
> would be best to place it as part of Geronimo initially, because it  
> is a good thing to have a concrete project [the appserver] to drive  
> the requirements.  Also, the featureset required to do Java EE is  
> somewhat less than the full CORBA spec (for instance, we have no  
> interface/implementation repository, and no IDL compiler).
>
> Our CORBA subsystem is written almost entirely by two people (of  
> which one is me), and so we would initially have two people on  
> this.  Depending on how this thing takes off we can add more people  
> over time.

Ok.  THat's good to know - code is somewhat useless without people  
and community around it.

There are a few process questions we need to answer :

First, the project committers (with PMC votes as binding...) should  
probably vote to go forward in general.  I think everyone is positive  
about this, but you certainly want to be sure before starting to make  
those changes.

Next, we need to decide where the code goes.  Right now this is hard  
because we don't have something tangible to talk about.  But keeping  
that in mind, putting it in the Apache Incubator isn't a bad thing if  
we're committed to working with you to drive how this fits into  
Geronimo.  In fact, that would give  you the ability to continue to  
commit directly to the codebase without having to earn commit status  
in the Geronimo project, as you would get commit status in the  
Incubator when you made the contribution.

[SNIP]

>
> A final side note: internally we call this CORBA project "Navajo,"  
> as the IIOP protocol is appropriately backwards and obscure to be  
> named after the indians that were employed to relay secret messages  
> in the pacific during WWII :-), see http://www.history.navy.mil/ 
> faqs/faq61-2.htm
>

Great, but if we could avoid carrying this name here, that would be  
good.  There is too much history around sensitivity to native  
american names here, and we should not agitate anyone even with the  
best of intentions in mind.

>
>
> Anyway, here is the "first project" I am thinking of...
>
>
> == first project ==
>
> Right now the Trifork ORB is using NIO for the server-side of IIOP,  
> but "classic" IO for the client side.  The NIO part is great  
> because it lets us run all corba handling in a single selector  
> thread backed by the appserver's thread pool.  However, With the  
> experience from working with this for the last 5 years, I would  
> like to redo the core I/O subsystem, and so I have started to do  
> the first steps towards this rework.
>
> The benefits of this, apart from cleaning up code that has grown  
> over time, would be:
>
> - Reduce copying data through the stack.
> - Reduce thread usage further to support even more clients.
> - Off-load reading&writing - e.g. response writing to the framework  
> so as to better handle slow clients.
>
> There are many reasons why I would like to do this, here is one:    
> One optimization that we did at one point was to pool byte arrays,  
> because the allocation of byte arrays (read: zeroing out memory)  
> took way too much time. [I know - generally pooling in JVM's is a  
> bad idea, but in this case it made a lot of sense]  With this  
> rewrite we would gain the same optimization one more time.  CORBA  
> Input/OutputStreams should be backed by java.nio.ByteBuffers  
> directly, which will then be passed straight down to the NIO  
> interface.
>
> The effort as I see it falls in two parts:
>
> - Asynchroneous I/O API (AIO).  Based on the abstractions we have  
> internally in the ORB, I'm doing a generalized version of something  
> very similar to IBM's aio4j; future-based socket I/O. Unline aio4j  
> however, the API runs straight on top of a Java SE 1.4 [no native  
> code], and hooks into an external thread pool to provide the same  
> API based on both NIO and "classic" IO technology.
>
> - IIOP Streams on AIO. Based on the above, write InputStream/ 
> OutputStream implementations, as  well as connection management,  
> backed by the AIO infrastructure and NIO direct buffers such that  
> the underlying OS can stream data straight into the high-level  
> structures.

Great.  Could this work be done here at Apache?

geir


-- 
Geir Magnusson Jr                                  +1-203-665-6437
geir@optonline.net