Emmanuel Lecharny wrote: > >>> I don't see the advantage of using byte[] honestly - using at the least >>> a wrapper object seems preferable. And if you're going to use a wrapper >>> object, why not just use ByteBuffer. >>> >> >> I'd prefer to introduce an interface type because ByteBuffer is >> impossible to extend. I can do some quick and dirty coding to prove the >> concept. How does it sound? >> > Defining an interface won't be helpfull... It will end up with almost > the very same implementation than the one we currenlty have (IoBuffer). > > If you consider the reasons why IoBuffer was created (ie, loosy BB > interface, not expandable), I think that David's idea to define a helper > class seems slightly better. > > For instance, BufferUtils.getLong( ByteBuffer ) or such methods can be > as convenient. > > (That's a pity we can't extend ByteBuffer...)
Indeed. The interface I am trying to introduce is something smaller than IoBuffer. It's rather close to what ByteBuffer offers. Simple getters and setters for primitive types. We have static imports, so introducing such a utility class shouldn't be a problem. >> Allocating a pre-sized buffer per connection can cause OOM when there >> are massive number of idle connections. > +1 >> We could use composite buffer >> in this case too because we can adjust the size of the buffer more >> flexibly without causing reallocation. >> > Creating a BB is not costly in java 6. The idea would be to create BB > with the best possible size depending on the network capability (of > course, that mean we have some way to know what is the best size ...) > >> Gathering write is also a piece of cake if composite buffer is realized. >> Of course it should be friendly with your suggested allocation >> mechanism. >> > I remember having read some post about gathering writes, where it is > explained that you should not take care of that on the BB level, as the > JVM will handle it by itself. Jean-François Arcan's post may be ? Hmm I don't remember. At least you have to provide an array of ByteBuffers to perform gathering write or scattered read? >> <snip/> >> >> Thanks for mentioning all possibilities. I'm leaning toward to my >> original idea of providing byte array abstraction and buffer state >> abstraction types because it can cover all cases you've mentioned. >> Also, we can provide the sheer number of getters and putters for users >> who like them anyway - it should end up with much simpler one monolithic >> class - a way simpler. >> > That would be good ! And easier for people who want to enter the API to > maintain it ! I even find such a monolithic stuff might not be needed if we are going to use utility classes backed by static imports. So.. The changes I am proposing is all about simplification sacrificing backward compatibility. This might affect people who are using MINA 2 M1 or trunk. We had to think about all these issues before recommending people to use 2 M1 and placing the download links in the very top of the download page. (we could move the links to the unstable releases section.) -- Trustin Lee - Principal Software Engineer, JBoss, Red Hat -- what we call human nature is actually human habit -- http://gleamynode.net/
signature.asc
Description: OpenPGP digital signature
