Io prefix:
[X]: Retain them.
Rename ByteBuffer to may be WrapperByteBuffer or ExtendedByteBuffer
Arul Kumaran
Senior Java/J2EE developer/designer
http://www.lulu.com/java-success
-Original Message-
From: Maarten Bosteels [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 18 September 2007
Trustin Lee wrote:
Hi folks,
It is often confusing to discriminate MINA ByteBuffer and NIO
ByteBuffer. Do we need renaming? I didn't have much difficulties
actually because most Java code doesn't use both types at the same
time.
There was an opinion about renaming it to MinaByteBuffer,
MinaByteBuffer would fit me. I don't like OctetBuffer too much, even
if I'm french. What if M$ sudddenly decide that an Octet is 9 bits (8
bits for the data, plus 1 bit as a M$ tax to pay M$ fin to the EU ?:)
On 9/18/07, Niklas Therning [EMAIL PROTECTED] wrote:
Trustin Lee wrote:
Hi folks,
I agree with the comment of not suffixing with ByteBuffer since it
incorrectly suggests that it's a subclass of the Java standard.
I don't think just Buffer would be good because of the single word, which
would normally describe an interface.
So that's why I voted to something simple as
LOL! I have to agree on DataBuffer, it sounds nice. OctetBuffer sounds a
little too farfetched, IMO.
Jeroen Brattinga
Emmanuel Lecharny wrote:
MinaByteBuffer would fit me. I don't like OctetBuffer too much, even
if I'm french. What if M$ sudddenly decide that an Octet is 9 bits (8
bits for
I guess M$ would have to redefine the Greek (or is it Latin?) language
then as well. :-)
Seriously, I think DataBuffer or Buffer would be ok. On second thought
MinaByteBuffer is ok too. I don't think it will be very confusing. It
will certainly be less confusing than what we have at the moment.
[x] DataBuffer
Maarten
On 9/18/07, Niklas Therning [EMAIL PROTECTED] wrote:
I guess M$ would have to redefine the Greek (or is it Latin?) language
then as well. :-)
Seriously, I think DataBuffer or Buffer would be ok. On second thought
MinaByteBuffer is ok too. I don't think it will be
When you have protocol _data_ it makes sense that the object is called
DataBuffer.
;-)
On 9/18/07, Jeroen Brattinga [EMAIL PROTECTED] wrote:
LOL! I have to agree on DataBuffer, it sounds nice. OctetBuffer sounds a
little too farfetched, IMO.
Jeroen Brattinga
Emmanuel Lecharny wrote:
MINAByteBuffer, because it's MINA, not Mina and I like obvious names :)
Julien
On Tue, 18 Sep 2007 10:14:56 +0900
Trustin Lee [EMAIL PROTECTED] wrote:
Hi folks,
It is often confusing to discriminate MINA ByteBuffer and NIO
ByteBuffer. Do we need renaming? I didn't have much difficulties
I would choose MINADataBuffer as there is a java.awt.image.DataBuffer.
Regards
Boon Ping.
On 9/18/07, Julien Vermillard [EMAIL PROTECTED] wrote:
MINAByteBuffer, because it's MINA, not Mina and I like obvious names :)
Julien
On Tue, 18 Sep 2007 10:14:56 +0900
Trustin Lee [EMAIL PROTECTED]
ExtendedByteBuffer, because it provides additional features to the
standard ByteBuffer.
On 9/18/07, Julien Vermillard [EMAIL PROTECTED] wrote:
MINAByteBuffer, because it's MINA, not Mina and I like obvious names :)
Julien
On Tue, 18 Sep 2007 10:14:56 +0900
Trustin Lee [EMAIL PROTECTED]
MinaByteBuffer is not really making muxch sense here. We move from
IoSession to IOSession and choose to use Mina in place of MINA ?
Julien
On Tue, 18 Sep 2007 09:56:50 +0200
Emmanuel Lecharny [EMAIL PROTECTED] wrote:
MinaByteBuffer would fit me. I don't like OctetBuffer too much, even
if I'm
Hello Trustin,
I ran the code on Windows XP jdk 1.6 , and this is the output I got:
Local host: kweenie/172.29.100.104
Open: (datagram, server, /172.29.100.104:5678 = /0.0.0.0:1234)
Received: (datagram, server, /172.29.100.104:5678 = /0.0.0.0:1234),
HeapBuffer[pos=0 lim=2 cap=2048: 00 00]
For the sake of some kind of consistency, DataBuffer.
MINAByteBuffer will break the previous poll (capitalize only first letter).
And talking about greeks : Timeo Microsoftaens et dona ferentes ...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
On linux 2.6.9, jdk 1.6
Local host: mortimer/172.30.6.12
Open: (datagram, server, /172.30.6.12:5678 = /0:0:0:0:0:0:0:0:1234)
Received: (datagram, server, /172.30.6.12:5678 = /0:0:0:0:0:0:0:0:1234),
HeapBuffer[pos=0 lim=1 cap=2048: 00]
Received: (datagram, server, /172.30.6.12:5678 =
Hi all,
I don't know too much about Mina so forgive me if I say anything stupid!
I have hit a problem with my own hacked about version of ApacheDS. ApacheDS is
an LDAP server which uses Mina 1.1.2 for its replication service.
The problem I am experiencing is that I have a replication (write)
On SunOS 5.10 sun4u sparc SUNW,Sun-Fire-V890
java version 1.5.0_01
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_01-b08)
Java HotSpot(TM) Server VM (build 1.5.0_01-b08, mixed mode)
Open: (datagram, server, /10.0.0.120:5678 = /0.0.0.0:1234)
Received: (datagram, server,
I'm not sure what HTTP server is being used, it's not my server, but it's
definitely not a Mina problem, I can reproduce the problem using just plain
sockets. Using Mina and writing out a 1.0 header, it works great.
Thanks.
Trustin Lee wrote:
What HTTP server are you using? Is it a
My vote is for MinaByteBuffer. Name it for what it is.
ExtendedByteBuffer is hard to rationalize since the class does not extend a
ByteBuffer.
WrappedByteBuffer is OK, but we already have a ByteBufferWrapper. This
could be confusing.
MINADataBuffer would be my second choice.
--
..Cheers
Mark
How many network devices exist in SunOS?
Thanks!
Trustin
On 9/18/07, Maarten Bosteels [EMAIL PROTECTED] wrote:
On SunOS 5.10 sun4u sparc SUNW,Sun-Fire-V890
java version 1.5.0_01
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_01-b08)
Java HotSpot(TM) Server VM (build
I have seen dozens on a box.
--
..Cheers
Mark
On 9/18/07, Trustin Lee [EMAIL PROTECTED] wrote:
How many network devices exist in SunOS?
Thanks!
Trustin
On 9/18/07, Maarten Bosteels [EMAIL PROTECTED] wrote:
On SunOS 5.10 sun4u sparc SUNW,Sun-Fire-V890
java version 1.5.0_01
I say DataBuffer or MinaByteBuffer
On 9/18/07, Trustin Lee [EMAIL PROTECTED] wrote:
Hi folks,
It is often confusing to discriminate MINA ByteBuffer and NIO
ByteBuffer. Do we need renaming? I didn't have much difficulties
actually because most Java code doesn't use both types at the same
On 9/18/07, Trustin Lee [EMAIL PROTECTED] wrote:
How many network devices exist in SunOS?
[EMAIL PROTECTED] # ifconfig -a
lo0: flags=2001000849UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL mtu 8232
index 1
inet 127.0.0.1 netmask ff00
ce0:
It seems like each broadcast packet is broadcasted as many times as
the number of network interface cards in Windows and SunOS. It's
interesting that Linux doesn't. Maarten, did I understand correctly?
I'd like to find a way to suppress the duplicate event emission, but
don't have any idea yet.
On 9/18/07, Trustin Lee [EMAIL PROTECTED] wrote:
It seems like each broadcast packet is broadcasted as many times as
the number of network interface cards in Windows and SunOS. It's
interesting that Linux doesn't. Maarten, did I understand correctly?
Yes, that's what I think as well,
I think we also need to check how our previous implementation works
with the test code.
Maarten, could you run the test again on Windows and SunOS with the
plain blocking I/O server instead of DatagramAcceptor?
CODE BEGINS
package net.gleamynode.tmp;
import
+0 DataBuffer
I also agree with the argument against using ByteBuffer in the name,
unless we actually change it to subclass the Java ByteBuffer. My vote
is slightly in favor of DataBuffer, but it still doesn't sound/feel
quite right to me. But I can't think of anything else at the moment
What about IoDataBuffer?
Jeroen Brattinga
Richard Wallace wrote:
+0 DataBuffer
I also agree with the argument against using ByteBuffer in the name,
unless we actually change it to subclass the Java ByteBuffer. My vote
is slightly in favor of DataBuffer, but it still doesn't sound/feel
On Linux:
/172.30.6.12:5678, 1
/172.30.6.12:5678, 2
/172.30.6.12:5678, 3
/172.30.6.12:5678, 4
Notice that the linux box has only 1 physical network card (and one virtual
interface)
eth0 Link encap:Ethernet HWaddr 00:11:43:2D:3C:29
inet addr:172.30.6.12 Bcast:172.30.255.255
I like IoBuffer.
Look at the documentation...
http://mina.apache.org/documentation.html
The basic constructs are:
* ByteBuffer
* IoService
* IoHandler
* IoFilter
* IoFuture
Which one doesn't fit?
Cameron
On 9/18/07, Rob Butler [EMAIL PROTECTED] wrote:
No one likes
IoBuffer is OK for me, certainly better than MinaByteBuffer
Maarten
On 9/18/07, Cameron Taggart [EMAIL PROTECTED] wrote:
I like IoBuffer.
Look at the documentation...
http://mina.apache.org/documentation.html
The basic constructs are:
* ByteBuffer
* IoService
* IoHandler
Do I need to change my current codec using ByteBuffer?
On 9/19/07, Maarten Bosteels [EMAIL PROTECTED] wrote:
IoBuffer is OK for me, certainly better than MinaByteBuffer
Maarten
On 9/18/07, Cameron Taggart [EMAIL PROTECTED] wrote:
I like IoBuffer.
Look at the documentation...
IoBuffer seems to be really consistent other stuff and sounds great to
me.
Arul Kumaran
Senior Java/J2EE developer/designer
http://www.lulu.com/java-success
-Original Message-
From: Cameron Taggart [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 19 September 2007 6:52 AM
To:
Thanks for clarification!
Trustn
On 9/18/07, squeebie [EMAIL PROTECTED] wrote:
I'm not sure what HTTP server is being used, it's not my server, but it's
definitely not a Mina problem, I can reproduce the problem using just plain
sockets. Using Mina and writing out a 1.0 header, it works
What we've found so far:
1) Non-broadcast packets are working fine.
1) It is a normal behavior that multiple duplicate broadcast packets
are received in a multi-homed system.
2) Windows sends the received broadcast packet to the unconnected
socket, too (i.e. both to the connected and the
After reading this thread over and giving it some thought, I like
IoBuffer best. It's the most consistent with the rest of the API.
DataBuffer would be my second pick.
-Mike
Trustin Lee wrote:
Hi folks,
It is often confusing to discriminate MINA ByteBuffer and NIO
ByteBuffer. Do we need
Sounds like we need to retain those 'Io's! :)
Thanks everyone!
Cheers,
Trustin
On 9/19/07, Mike Heath [EMAIL PROTECTED] wrote:
[x]: Retain them. I use JMS Session and java.util.concurrent.Future
everywhere!
--
what we call human nature is actually human habit
--
On 9/19/07, Mike Heath [EMAIL PROTECTED] wrote:
After reading this thread over and giving it some thought, I like
IoBuffer best. It's the most consistent with the rest of the API.
DataBuffer would be my second pick.
+1. I love IoBuffer, too. Is it time for vote then? It seems like
each
On 9/19/07, Trustin Lee [EMAIL PROTECTED] wrote:
What we've found so far:
1) Non-broadcast packets are working fine.
I found an interesting behavior (probably JVM or Windows bug). It
seems like it is who calls receive() or read() first that receives
non-broadcast packets. It doesn't mean any
39 matches
Mail list logo
