AbstratPollingStuff... renaming

[Julien Vermillard <jv...@archean.fr>]

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 configuration).

Those class aren't "polling" in a loop for checking session status,
it's the law level kernel/system implementation which does it.


So I we need to rename it to something making more sense and it's
javadoc less, so it's an opportunity to document this important part of
MINA internals ;)


I propose
- AbstractEventIo(Acceptor/Connector/..)
- AbstractSelectIo(Acceptor/Connector/..)
- AbstractAsyncIo(Acceptor/Connector/..)

even the Io could be removed.

WDYT ?

Julien

Re: AbstratPollingStuff... renaming

[Julien Vermillard <jv...@archean.fr>]

On Tue, 10 Jun 2008 17:08:30 -0600
Mike Heath <mh...@apache.org> 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 select
> > depending of the JVM/OS configuration).
> >
> > Those class aren't "polling" in a loop for checking session status,
> > it's the law level kernel/system implementation which does it.
> >   
> That's not really true.  These classing are in fact in a loop that 
> continually checks for network events that need to be processed.  The 
> check for network events is handled efficiently by the OS so that if 
> there are no events to process the thread will block until there is 
> something to process.  The system level mechanism for handling
> network events (epoll, kqueue, /dev/epoll, etc.) doesn't change the
> fact that there is still looping being done to capture and process
> network events and therefor these classes are indeed polling.
> 
> Additionally, in academia, "event-driven" and "polling" are often
> used interchangeably when referring to low level network APIs.  IIRC,
> the Stevens book uses the terms interchangeably as well.  So, anyone
> with significant experience in network programming will recognize the
> meaning of the "polling" nomenclature.
> 
> So, I wouldn't say those classes are "badly named".  That being said,
> it wouldn't bother me if these classes were renamed to use "select"
> since that is the NIO nomenclature.
> 
> -Mike
> 
> <snip>
> 

Hi Mike

I think for most of programmer polling is checking a status in a loop
with a given wait time.

It's well explained in
http://en.wikipedia.org/wiki/Polling_(computer_science)
'Polling' as used in Unix poll() system call is ambiguous and IMO not
really error prone. 
For example if you ask to the electronic guy on the desk on my
left, for him polling is checking in a loop the status of a
device/register. The polling used for checking I/O as we know it in
system programming should be called something like "interrupted
polling" or "active polling".

Well anyway the name is not that important because it's just support
classes, the important is to document it ;)

Julien

Perhaps as Emmanuel said "select" is more java programmer friendly.

Julien

Re: AbstratPollingStuff... renaming

[Mike Heath <mh...@apache.org>]

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 loop for checking session status,
> it's the law level kernel/system implementation which does it.
>   
That's not really true.  These classing are in fact in a loop that 
continually checks for network events that need to be processed.  The 
check for network events is handled efficiently by the OS so that if 
there are no events to process the thread will block until there is 
something to process.  The system level mechanism for handling network 
events (epoll, kqueue, /dev/epoll, etc.) doesn't change the fact that 
there is still looping being done to capture and process network events 
and therefor these classes are indeed polling.

Additionally, in academia, "event-driven" and "polling" are often used 
interchangeably when referring to low level network APIs.  IIRC, the 
Stevens book uses the terms interchangeably as well.  So, anyone with 
significant experience in network programming will recognize the meaning 
of the "polling" nomenclature.

So, I wouldn't say those classes are "badly named".  That being said, it 
wouldn't bother me if these classes were renamed to use "select" since 
that is the NIO nomenclature.

-Mike

<snip>

Re: AbstratPollingStuff... renaming

[Mark Webb <el...@gmail.com>]

sounds good to me.


On Tue, Jun 10, 2008 at 9:44 AM, Julien Vermillard
<jv...@archean.fr> 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 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 for checking session status,
> it's the law level kernel/system implementation which does it.
>
>
> So I we need to rename it to something making more sense and it's
> javadoc less, so it's an opportunity to document this important part of
> MINA internals ;)
>
>
> I propose
> - AbstractEventIo(Acceptor/Connector/..)
> - AbstractSelectIo(Acceptor/Connector/..)
> - AbstractAsyncIo(Acceptor/Connector/..)
>
> even the Io could be removed.
>
> WDYT ?
>
> Julien
>

Re: AbstratPollingStuff... renaming

[Emmanuel Lecharny <el...@apache.org>]

> 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, Select and Async 
we are working on, IMHO.

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: AbstratPollingStuff... renaming

[peter royal <pe...@pobox.com>]

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

[Emmanuel Lecharny <el...@apache.org>]

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