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: dev@mina.apache.org Subject: Re: New name for ByteBuffer? 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 eh.. Honestly it seems like the best name to me. > > ----- Original Message ---- > From: Jeroen Brattinga <[EMAIL PROTECTED]> > To: dev@mina.apache.org > Sent: Tuesday, September 18, 2007 12:04:14 PM > Subject: Re: New name for ByteBuffer? > > 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 > > quite right to me. But I can't think of anything else at the moment > > and I think it's the best of what's been suggested so far. > > > > Rich > > > > Rodrigo Madera wrote: > >> 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 xxxBuffer, which in this > >> case > >> was DataBuffer as Trustin suggested. > >> > >> Regards, > >> Rodrigo > >> > >> On 9/18/07, Niklas Therning <[EMAIL PROTECTED]> wrote: > >> > >>> 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, but I don't > >>>> think it's the best name available for us. I think DataBuffer, > >>>> ExtendedByteBuffer, ExtendedBuffer or just Buffer might also be a > >>>> candidate. There's Buffer in NIO, too, but nobody uses that class > >>>> directly. > >>>> > >>>> I'd like to find the best name; short and not confusing one. Please > >>>> don't hesitate to respond to this message with your idea so we can > >>>> find out the best alternative. > >>>> > >>>> Trustin > >>>> > >>>> > >>> Since MINA's ByteBuffer doesn't inherit from java.nio.ByteBuffer I > >>> think > >>> the names ending in ByteBuffer (especially ExtendedByteBuffer) could be > >>> confusing. I think I prefer just calling it Buffer. > >>> > >>> Or maybe OctetBuffer? According to Wikipedia > >>> (http://en.wikipedia.org/wiki/Octet_%28computing%29): > >>> > >>> "Octet, with the only exception noted below, always refers to an entity > >>> having exactly eight bits. As such, it is often used where the term > >>> byte > >>> might be ambiguous. For that reason, computer networking standards > >>> almost exclusively use octet." > >>> > >>> Also > >>> > >>> "In France, French Canada and Romania, the word octet usually means > >>> byte" > >>> > >>> This would make all the French and Romainian MINA users happy! :-) > >>> > >>> -- > >>> Niklas Therning > >>> www.spamdrain.net > >>> > >>> > >>> > >> > >> > > > > > > > > > > > > ________________________________________________________________________ ____________ > Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. > http://smallbusiness.yahoo.com/webhosting > *********************************************************** CAUTION: This email and files included in its transmission are solely intended for the use of the addressee(s) and may contain information that is confidential and privileged. If you receive this email in error, please advise us immediately and delete it without copying the contents contained within. Woolworths Limited (including its group of companies) do not accept liability for the views expressed within or the consequences of any computer viruses that may be transmitted with this email. The contents are also subject to copyright. No part of it should be reproduced, adapted or transmitted without the written consent of the copyright owner. ***********************************************************
