First thought about class in o.a.m.common : I tried to give a category for each class (buffer,service,future,etc..)
IoBufferHexDumper.java buffer SimpleBufferAllocator.java buffer BufferDataException.java buffer IoBuffer.java buffer IoBufferWrapper.java buffer AbstractIoBuffer.java buffer IoBufferAllocator.java buffer CachedBufferAllocator.java buffer DefaultFileRegion.java file FileRegion.java file IoFilter.java filterchain IoFilterLifeCycleException.java filterchain IoFilterChainBuilder.java filterchain IoFilterChain.java filterchain IoFilterEvent.java filterchain IoEvent.java filterchain IoFilterAdapter.java filterchain IoEventType.java filterchain UnknownMessageTypeException.java filterchain/demux IoFuture.java future WriteFuture.java future DefaultCloseFuture.java future IoFutureListener.java future CloseFuture.java future CompositeIoFuture.java future ConnectFuture.java future DefaultWriteFuture.java future DefaultIoFuture.java future DefaultReadFuture.java future DefaultConnectFuture.java future ReadFuture.java future AbstractPollingIoConnector.java polling AbstractPollingIoAcceptor.java polling AbstractPollingIoProcessor.java polling AbstractPollingConnectionlessIoAcceptor.java polling WriteToClosedSessionException.java service TransportMetadata.java service SimpleIoProcessorPool.java service NothingWrittenException.java service IoHandlerAdapter.java service IoHandler.java service IoProcessor.java service IoServiceListenerSupport.java service IoServiceListener.java service IoService.java service AbstractIoAcceptor.java service DefaultIoFilterChain.java service DefaultTransportMetadata.java service DefaultWriteRequest.java service AbstractIoConnector.java service AbstractIoService.java service DefaultIoFilterChainBuilder.java service ExpiringSessionRecycler.java service IoAcceptor.java service IoConnector.java service AbstractIoSessionConfig.java session IdleStatus.java session WriteException.java session AttributeKey.java session AbstractIoSession.java session WriteRequestWrapper.java session WriteTimeoutException.java session DummySession.java session TrafficMask.java session WriteRequestQueue.java session WriteRequest.java session IoSessionDataStructureFactory.java session IoSessionInitializationException.java session IoSessionInitializer.java session DefaultIoSessionDataStructureFactory.java session IoSessionAttributeMap.java session IoSessionConfig.java session IdleStatusChecker.java session IoSessionRecycler.java session IoSession.java session DefaultExceptionMonitor.java ? RuntimeIoException.java ? IoUtil.java ? ExceptionMonitor.java ? Anyway this package is now bloated ;) BTW I'm out of office for 1 week. Julien On Mon, 09 Jun 2008 13:05:24 +0200 Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > Ok, ok, I have to admit that my proposal was not that good :) > > So let's move to something more sane, which seems to gather more > approval : reviewing the packages we have in mina-core. > > More to come... > > > Mark Webb wrote: > > +1 > > > > On Mon, Jun 9, 2008 at 1:31 AM, Alex Karasulu > > <[EMAIL PROTECTED]> wrote: > >> I don't really have a specific view point on this topic. I would > >> rather have more efficient and easily maintained internals. I > >> don't know if this accomplishes that but I'm sure you guys can > >> hash that out. > >> > >> Regards, > >> Alex > >> > >> On Mon, Jun 9, 2008 at 1:07 AM, Emmanuel Lecharny > >> <[EMAIL PROTECTED]> wrote: > >> > >> > >>> Mark Webb wrote: > >>> > >>> > >>>> I do not think this is a good idea. > >>>> > >>>> > >>>> > >>> Looking at the three answers, it seems so ;) > >>> > >>> 3. We may confuse things for alot of people who may already be > >>> using > >>>> 2.0. Telling users that they will have to fix their code > >>>> because of a re-organization looks bad on our part IMHO. > >>>> > >>>> > >>>> > >>> Regardless to the refactoring question, this is the kind of risk > >>> we have to consider, in any case. More than confusing the users > >>> who have based their code on the current 2.0 stack, I think it's > >>> much more important to build a coherent stack we will live with > >>> for a long time. Waiting for a 3.0 version and differing > >>> refactoring just because we have users of the current trunk is > >>> certainly not a good idea. Trunk is trunk, using it is a risk, > >>> and it's well know. > >>> > >>> Thanks ! > >>> > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> -- > >>> cordialement, regards, > >>> Emmanuel Lécharny > >>> www.iktek.com > >>> directory.apache.org > >>> > >>> > >>> > >>> > > > > > >
signature.asc
Description: PGP signature
