"이희승 (Trustin Lee) <[EMAIL PROTECTED]>" wrote:
Why do you want to protect those internal values ? The contract is
pretty clear, and if a user fucks with those values, eh, too bad for him !
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.
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.
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...
But I do think that as soon as you have been burnt once with the limit,
position and mark, as a smart user, you RTFM and try to respect the API
contract :)
That's what's called 'bad impression' IMHO. API should respect the user
before the user respects the API.
<IMHO>
Actually, I think it should be the opposite : Users should respect the
API, and the API should respect the user who respects the API...
As a matter of fact, the french law system says that everything which is
not strictly forbidden by law is authorized, which is much more
powerfull than the opposite position : you can only do what the law
authorizes. (I guess it's the same in any democratic country). An API
should be as permissive as the law.
That don't mean you can't derive a more strict API on top of BB (this is
what we currently have), but at some point, you have to question
yourself : "is it valuable ?". Here, I think the cost is too high in
many respects :
- huge code has to be written (13% of the total MINA code base)
- users have to learn a new API
- as users are lazzy (we all are...), they will make mistakes using the
new API, so we will spend more time fixing their errors
- performances will be lower, because we will stack another layer on top
of the existing one
- 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.
</IMHO>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
