yep. +1
On 7/7/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > On Jul 7, 2005, at 1:17 PM, Aaron Mulder wrote: > > > I dunno, if it's going to take 4 months for TriFork to finish > > releasing the code, I'm all in favor of picking a home ASAP so it > > doesn't > > slip further. > > > > I think the incubator is the best, as everyone who needs to can > > get access to it there, I think some incubation steps are required > > for any > > pre-existing donated code anyway (for legal/IP reasons), and we can > > delay > > the decision of whether it goes into a Geronimo subproject or a > > project > > of its own until it actually is ready to leave the incubator. > > To be clear, the incubation steps can happen in parallel - it doesn't > require a "quarantine visit" or such in incubator SVN repo. It can > come directly here if we choose, and do the documentation at the same > time. > > geir > > > > > > I'm not sure the ActiveIO question is all that relevant, since I'm > > assuming IO is a small part of the ORB. That is, if they want to > > enhance > > and use ActiveIO, that can become a library dependency for the > > incubator > > ORB module. If they choose to start with their own IO code, they > > can put > > it in the incubator, adn then decide when/whether/how to replace it > > with > > ActiveIO or something else going forward. > > > > Aaron > > > > On Thu, 7 Jul 2005, Hiram Chirino wrote: > > > > > >> That's a possibility. I would not mind bringing the project into > >> apache if it will help grow the community. > >> But I think the first step is to see if activeio is the kind of think > >> that new Trifork orb is interested in. > >> > >> Regards, > >> Hiram > >> > >> On Jul 7, 2005, at 12:16 PM, Davanum Srinivas wrote: > >> > >> > >>> Hiram, > >>> > >>> Could you please make sure that the project gets worked on here at > >>> Apache? Am a bit concerned about code getting forked out and then > >>> becoming geronimo becoming a dependency on an external project. If > >>> activeio folks want to come here and join forces with trifork folks, > >>> that would be ideal IMHO. > >>> > >>> thanks, > >>> dims > >>> > >>> On 7/7/05, Hiram Chirino <[EMAIL PROTECTED]> wrote: > >>> > >>> > >>>> Hi Kresten, > >>>> > >>>> On Jul 4, 2005, at 11:53 AM, Kresten Krab Thorup wrote: > >>>> > >>>> > >>>>> > >>>>> == 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. > >>>>> > >>>>> > >>>>> > >>>> > >>>> This area of work is absolutely fascinating for me. It seems > >>>> that in > >>>> ActiveMQ we have very similar requirements to your ORB. A > >>>> standalone > >>>> project was started to deal with exactly those issues at http:// > >>>> activeio.org. We built a flexible IO abstractions so that a client > >>>> application can choose the API and implementation technology that > >>>> best suites it's needs. Clients can choose to use a synchronous > >>>> packet, asynchronous packet, or a synchronous stream interface. > >>>> The > >>>> And the client can choose what underlying IO technology will > >>>> implement the chosen interface, it could choose to use standard > >>>> blocking IO, or use NIO in blocking mode, or NIO in non-blocking > >>>> mode, or IBM AIO, or JXTA sockets, or jvm pipes, etc. etc. > >>>> All of this has already been implemented and is ASL 2.0 licensed > >>>> and > >>>> being used by Geronimo and ActiveMQ. Since you've been thinking > >>>> this, it would be good to chat to see if it would suite your > >>>> needs or > >>>> if needs enhancing. > >>>> > >>>> Regards, > >>>> Hiram > >>>> > >>>> > >>>> > >>>> > >>>>> - 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. > >>>>> > >>>>> Kresten > >>>>> > >>>>> > >>>>> On Jul 4, 2005, at 2:37 PM, Geir Magnusson Jr. wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> Joern, > >>>>>> > >>>>>> Thanks for the note. This is the right place to discuss. > >>>>>> > >>>>>> There are two separate threads of discussion that I can think > >>>>>> of : > >>>>>> > >>>>>> 1) Technical - if the donation fits technically into what we are > >>>>>> doing (I'm sure it does...) > >>>>>> > >>>>>> 2) Administrative - how, where and when > >>>>>> > >>>>>> As for #2 my questions to you are : > >>>>>> > >>>>>> a) What is the timing for this donation? How soon? > >>>>>> > >>>>>> b) Do you see this as coming straight to Geronimo to be part of > >>>>>> Geronimo initially, or to the Apache Incubator where we could > >>>>>> work > >>>>>> on it with you and then make the decision of coming to the > >>>>>> Geronimo project or being something else, like a stand-alone top- > >>>>>> level project. > >>>>>> > >>>>>> c) I assume that you'd be offering committers to help us with the > >>>>>> codebase and to continue working and expanding. Do you have an > >>>>>> idea of how many? > >>>>>> > >>>>>> Thanks for doing this, and we look forward to discussion on both > >>>>>> subjects above. > >>>>>> > >>>>>> geir > >>>>>> -- > >>>>>> Geir Magnusson Jr > >>>>>> +1-203-665-6437 > >>>>>> [EMAIL PROTECTED] > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> -- > >>> Davanum Srinivas -http://blogs.cocoondev.org/dims/ > >>> > >>> > >> > >> > >> > > > > > > -- > Geir Magnusson Jr +1-203-665-6437 > [EMAIL PROTECTED] > > > -- Davanum Srinivas -http://blogs.cocoondev.org/dims/
