On Tue, 10 Jun 2008 17:08:30 -0600
Mike Heath [EMAIL PROTECTED] wrote:
Julien Vermillard wrote:
snip
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
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
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 calls
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
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
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,
Julien Vermillard wrote:
snip
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
