John Fallows wrote:
Thanks for your reply, Emmanuel, and thanks for fixing the bug.
Is there any documentation of the discussion regarding the upcoming change
of public API between 2.0-beta-3 and 2.0 final?
Not really. What we have is a roadmap on JIRA, but AFAIK, it's not up to
date (I know, this is bad ;)
Perhaps you are planning to leave IoBuffer as deprecated to ease migration
from 1.0 to 2.0?
This is a difficult decision. There are already a lot of modification
between those two versions, and I don't think that moving from IoBuffer
to InputStream is, from the users perspective, such a big deal. But
anyway, this is still a pending modification.
Is the change of strategy an extension of the thinking behind the desire for
CompositeIoBuffer?
It's a move forward the CompositeIoBuffer (or some sort of structure),
which allows :
- a simpler way to manipulate data in the chain (when you have decoded
some message, it's not anymore a IoBuffer, but you don't have a common
interface. With an InputStream, be it a ByteBufferInputStream or a
MessageInputStream, this is way easier)
- a way to remove all the IoBuffer code, which represent a complete
wrapper on top of the nio ByteBuffer, simply for offer extensible
buffers (an error, IMHO : buffers should _not_ be extensible : they are
just temporary storage by essence).
- and a way to keep the extensibility needed when dealing with splitted
messages.
Will there be an opportunity to evaluate the new API in an upcoming 2.0-beta
before the 2.0-final release?
Yeah, sure. There will be most certainly a M4 and probably a M5 before a
RC1. When ? No idea...
Btw, some open source projects don't enjoy the file-bug-first strategy, and
prefer to verify the bug on the mailing list first. I understand from your
feedback that filing bugs first is okay, and that detailed, code-specific
issues such as this should be addressed to the development mailing list
instead of the users mailing list, so I'll subscribe to that list before
posting about such potential bugs in future.
The idea is to avoid losing important messages. JIRA is good for that,
of course if you attach your JIRA to a specific version, as it don't
vanish. When we cut a release, we try our best to close all the
associated JIRAs, or, at least, to postpone them. Mails, well, they are
simply forgotten after a few days ;)
Even a JIRA which is not a bug is better than a mail, as we just have to
dismiss it : a very simple operation.
Now, I understand that some OSS project don't like issues like "Your
project has a bug" when 99% of the time, it's a user issue. It's just a
question of balance, IMO. Sometime, it's better to post first, and if
you don't get a response, post again, or create a JIRA.
In any case, when we ask for a JIRA, it's also a sign that there may be
something important we don't want to miss.
Thanks !
Kind Regards,
John Fallows.
On Mon, Oct 20, 2008 at 5:21 AM, Emmanuel Lecharny <[EMAIL PROTECTED]>wrote:
John Fallows wrote:
Folks,
I think there might be a bug in AbstractIoBuffer.getSlice(index, length)
in
Mina 2.0.0-M3.
public final IoBuffer getSlice(int index, int length) {
if (length < 0) {
throw new IllegalArgumentException("length: " + length);
}
int pos = position();
int limit = limit();
int endIndex = *pos* + length;
...
limit(endIndex);
Shouldn't that be:
int endIndex = *index* + length;
...
limit(endIndex);
Otherwise, the wrong slice would be returned if index differs from the
current position, right?
Seems right.
FYI, the IoBuffer class is likely to be removed in the final version of
MINA, and AFAIK, the getSlice( int, int ) method is neither used nor
documented, so the question is : does it worth the effort to fix it and
document it ? It seems that YAGNI hasen't been applied in this area ... (
http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It)
Thanks for pointing the bug (I will fix it)
Btw, you should either post such a mail to the dev mailing list, or better,
create a JIRA (with possibly a proposed patch).
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
