"이희승 (Trustin Lee) <[EMAIL PROTECTED]>" wrote:
Emmanuel Lecharny wrote:
If those internal values shouldn't be modified, then there should be
zero possibility. Otherwise, it's not internal and the contract is too
loose. API should minimize user's mistake wherever possible.
The pb is that BB should be seen as a 2 ways API : you can read a BB,
but you can also feed it with data. This is the reason why you can
modify the position, mark etc.
Would they want to protect those values, they would have provided
factories for a read-only BB.
Read only ByteBuffer doesn't mean read-only position, limit, etc.
Sure, but you get the idea: we don't really need to care about position,
limit,etc...
Gain, I think you are over-interpreting the BB semantic. They are just
Buffers, so they are just supposed to be transitory, not permanent. An
advised user should be aware of that, so I don't think we should be
over-pretective, because it comes to a price the user don't necessarily
want to pay.
Not all users use codec framework we provide, and users often build
their own filter which deals with buffers. They should be covered.
When a user comes to write a Filter, usually, he has quite a good
knowledge and is not a beginner. We should assume that we are dealing
with experienced users. (even if it's not the case)
If we do care, maybe another option would be to transform those BB to
byte[] and let the user play with the limits by himself...
Direct buffer is a show-stopper for that unfortunately.
True, you can't get a byte[] out of a direct buffer, but direct buffer
has a very specific semantic which is known by the user. If the user has
selected a direct buffer, he is aware that he can't manipulate bytes at
will. In any case, Direct buffers should not be used in the vast
majority of cases. Even the small performance tests you have conducted
show that Direct buffer perform slower than Heap buffer.
I do think that Direct BB should be used very carefully, and in the
spirit they were created for : video memory access, device memory
access, etc... Not as a speed up in a network framework...
According to my recent benchmark, Java 6 VM showed that a direct buffer
outperforms a heap buffer for a unknown reason.
Well, I would like to get some more specific benchmarks, and no micro
benchmarks, but anyway, this is not the thing we are discussing here.
Even if direct buffers are faster, we should _not_ use them just because
they are faster. There are many payload associated with direct buffers,
including the fact that you can simply kill a machine by eating all of
its memory, which is not possible with heap buffers. Again, direct
buffers were not created for such a general purpose.
The problem is
allocation and deallocation, but it is also possible to work around. Of
course, we should be careful, but it doesn't mean that we shouldn't
support a direct buffer.
We should support them, but BB already have support for them. Let's the
user decide what to do, and let him deal with the fact that some BB's
methods won't work when they are using direct buffers.
- huge code has to be written (13% of the total MINA code base)
It's because of the current implementation. It should be different in
the new implementation we are discussing now.
Sure
- users have to learn a new API
The number of classes they have to learn doesn't change much at all
considering the number of all MINA classes.
Yes, but no need to add a new one then :) KISS !
- as users are lazzy (we all are...), they will make mistakes using the
new API, so we will spend more time fixing their errors
The new API is more intuitive than NIO ByteBuffer IMHO.
Maybe. But not sure. And our users are supposed to know about BB already.
I think most
users know better about accessing an array and using Iterator than using
flip() and compact().
Iterator() is one of the few classes I really don't like to deal with.
Tis is cumbersome when debugging; as you have no way to know which will
be the next object until the next() method is called. It's a good
pattern for many complex collections, but when it comes to a byte array,
this is not exactly what comes in mind at first shot ...
I agree that flip() and compact() are also a burden... (I never used
compact, and I have been burnt by flip more than once, so...), but at
least, once you understand how works a BB, this should not be a problem.
We have received a lot of questions from users
who forgot to call flip() - they didn't even know what flip() is in many
cases.
Very true. And you will get more users question about the new API too.
Users may be unexperienced, that's life !
We don't get such a question now after we modified MINA to throw
an exception with some message ("call flip()").
Sometime, a good RTFM helps :)
However, why should we do such a runtime check when we can provide
something much easier to understand?
Ok, I see your point.
The basic idea here would be to offer two options depending on the
user's level :
- BB access for experienced users
- a layer on top of BB for dummies, with all the associated costs
I agree that BB API is losy, and that it's a pity it can't be extended,
and that we don't have subclasses for DirectBB and HeapBB, but for those
of us who are writing real stacks on top of MINA, I would rather deal
with BB API than having to pay the overload to learn a new API and pay a
price for using it in term of speed.
- performances will be lower, because we will stack another layer on top
of the existing one
I did performance test to make sure the performance doesn't get worse if
we use an interface to access a byte array. There was no performance loss.
You will have a performance loss, that's guaranteed. If you see no loss,
then it's because your measure were not accurate enough. Better say that
the performance loss will be minimal, but you have to be aware that you
will eat more CPU, more heap, more memory and more GC. There is nothing
bad about it, but it has to be known.
- you will loose some semantic, and hide some of it to the user, who for
instance may use Direct BB when they should not, simply because you
masked the underlying semantic.
I don't understand what you mean here. The default buffer will be heap
buffers and when users want to alocate a direct buffer, it should be
explicitly specified.
What I mean is that having a flag telling the API that the structure you
want to allocate is a Direct BB under the hood is not enough. The BB API
is losy in this respect too, as some of its method won't react the same
way depending o,n the kind of BB you have allocated (ie, the array()
method). Sun should have came with a DirectBB inheriting from a BB
interface in place of merging those two kind of BB. Anyway... The
important point is that Direct BB have their own semantic which is
totally different from Heap BB, and we should let the user deal with this.
Direct BB should _not_ be used in place of Heap BB just because the user
set a flag.
Of course, it's very different from calling position(int) or limit(int)
by mistake (?). They are sitting down there in front of users and the
users are supposed to make a mistake unless they are hidden, and we can
hide them in compilation time.
Users make mistakes, all the time :) Poor users ;)
Let's close this thread which becomes much more theorical than necessary :
- I buy the idea of having a 'uber' API which hide the intricacy of BB
to level 1 users
- I think that if we write such an API, we may want to expose two
interfaces : one for Heap BB and one for Direct BB
- I also want to be able to use nio BB without depending on this high
level abstraction, and I'm pretty sure that some Level 2 users will like
to do so.
wdyt ?
Thanks,
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
