Re: AbstratPollingStuff... renaming

2008-06-10 Thread Mike Heath
Julien Vermillard wrote: The polled is here because it's base classes for transport implementations using event strategy based on system calls behaving like poll() (which can be in fact poll, epoll, kqueue or select depending of the JVM/OS configuration). Those class aren't "polling" in a loop

Re: AbstratPollingStuff... renaming

2008-06-10 Thread Emmanuel Lecharny
I propose - AbstractEventIo(Acceptor/Connector/..) - AbstractSelectIo(Acceptor/Connector/..) - AbstractAsyncIo(Acceptor/Connector/..) Sorry, my previous mail was partial, I +1 the three proposals. even the Io could be removed. We can keep the Io to characterize the type of Event, Selec

Re: AbstratPollingStuff... renaming

2008-06-10 Thread peter royal
On Jun 10, 2008, at 6:44 AM, Julien Vermillard wrote: I propose - AbstractEventIo(Acceptor/Connector/..) - AbstractSelectIo(Acceptor/Connector/..) - AbstractAsyncIo(Acceptor/Connector/..) even the Io could be removed. WDYT ? +1 -pete -- (peter.royal|osi)@pobox.com - http://fotap.org/~osi

Re: AbstratPollingStuff... renaming

2008-06-10 Thread Emmanuel Lecharny
Julien Vermillard wrote: Hi, - AbstractSelectIo(Acceptor/Connector/..) This one sounds the best to me, as select() resonates with the java Selector class. -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org

[jira] Commented: (DIRMINA-596) Sessions generated by NioSocketConnector cannot be closed in time (within MINA2.0 M1,M2)

2008-06-10 Thread Nathanael Van Vorst (JIRA)
[ https://issues.apache.org/jira/browse/DIRMINA-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603987#action_12603987 ] Nathanael Van Vorst commented on DIRMINA-596: - I see something similar. I am u

Re: [2.0 refactoring] What about splitting mina-core ?

2008-06-10 Thread Alex Karasulu
Ersin, Thanks for suggesting this. This is exactly what I was thinking could help both camps. Many projects have a xxx-foo.jar, xxx-bar.jar and an xxx-all.jar which contains all packages. This also helps for OSGi'fication. Alex On Tue, Jun 10, 2008 at 8:51 AM, Ersin Er <[EMAIL PROTECTED]> wro

Re: AbstratPollingStuff... renaming

2008-06-10 Thread Mark Webb
sounds good to me. On Tue, Jun 10, 2008 at 9:44 AM, Julien Vermillard <[EMAIL PROTECTED]> wrote: > Hi, > > as Emmanuel stated, the AbstractPollingIoXXX class are badly named. > > The polled is here because it's base classes for transport > implementations using event strategy based on system call

AbstratPollingStuff... renaming

2008-06-10 Thread Julien Vermillard
Hi, as Emmanuel stated, the AbstractPollingIoXXX class are badly named. The polled is here because it's base classes for transport implementations using event strategy based on system calls behaving like poll() (which can be in fact poll, epoll, kqueue or select depending of the JVM/OS configurat

Re: [2.0 refactoring] What about splitting mina-core ?

2008-06-10 Thread Ersin Er
Hi, I would suggest having both a monolithic and a set of modular packages just as Spring Framework distribution has. Of course from the developers point of view there should be more packages and projects to make things more decoupled and understandable. They can all be compiled into separate jars

Re: [2.0 refactoring] Reviewing core packages was : [2.0 refactoring] What about splitting mina-core ?

2008-06-10 Thread Julien Vermillard
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.javabuffer IoBuffer.java buffer IoBufferWrapper.java

Re: [2.0 refactoring] What about splitting mina-core ?

2008-06-10 Thread Emmanuel Lecharny
'Multiple' starts at 2 ;) I would suggest we start by reorganizing the packages first, and then we may see if it really makes sense to split mina-core in 2 (or 3 ;) Thanks ! On Tue, Jun 10, 2008 at 5:25 AM, Mike Heath <[EMAIL PROTECTED]> wrote: > I agree with Maarten and Julien, multiple package