Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of dfs@savarese.org designates
 199.15.254.130 as permitted sender)
Message-Id: <201104131742.p3DHgnPR028737@aragorn.savarese.org>
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: Commons Net issues
In-reply-to: Your message of "Tue, 12 Apr 2011 19:46:38 BST."
             <BANLkTi=Sdgnt8W=-rJctHuN=-++8i0vrxw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 13 Apr 2011 13:42:49 -0400
From: "Daniel F. Savarese" <dfs@savarese.org>


In message <BANLkTi=Sdgnt8W=-rJctHuN=-++8i0vrxw@mail.gmail.com>, sebb writes:
>On 12 April 2011 18:59, Daniel F. Savarese <dfs@savarese.org> wrote:
>>
>> 1. NET-396 POP3.setState() should not be public
>
>OK, fine, let's revert that change.

Thanks.  I see you did it on your own, denying me a rare opportunity to
make a commit :)

>> 2. NET-393 Should the sendCommandWithID() methods be public?
...
>The IMAP code is brand new so there are no existing users.

OK, as I said, I'm not very familiar with the IMAP code and trust
your judgement on the issue.  Still, in light of the POP3.setState
change, I had to point out what the intended role of the base protocol
classes is.  There are a lot of things that look "bad" when working from
a certain set of assumptions  For example, SMTPClient.sendMessageData has
been criticized as bad design by people expecting the smtp package to be
like JavaMail as opposed to a means for low-level protocol access that
lets you do things like send very large attachments that don't fit in memory.

>> 3. NET-402 BufferedReader used for control channel, which does not follow
..
>That may well be the case, but I could not find that prohibition.

Each protocol has slightly different requirements, the wording of RFC's
sometimes changes when they get updated, and the interpretation the wording
will often vary by reader.  For NNTP at least, I think the restriction is
pretty clear.  Section 3.1.1 Multi-line Data Blocks specifies:
  1.  The block consists of a sequence of zero or more "lines", each
      being a stream of octets ending with a CRLF pair.  Apart from
      those line endings, the stream MUST NOT include the octets NUL,
      LF, or CR.

But that's really beside the point.

>Only if bare CR or LF are never allowed, otherwise using
>BufferedReader is a problem, and CRLFLineReader is an improvement.

I conceded that for the non-conforming (depending on the protocol) case
where bare CR/LF's occur in data, CRLFLineReader is an improvement
(factoring out the performance impact) and wasn't asking for a change.

>That was presumably before I got involved, because I'm not aware of
>that decision, and as far as I can tell it's not documented.

Yes, it goes back 14 years (as does POP3.setState being public).

>Since JIRA issues are reported to the mailing list, I assumed that
>developers would comment if they disagreed. I took the view (possibly
>incorrectly) that these weren't major changes which required a
>separate discussion.

I never saw the traffic, so I'll have to check my subscriptions and my
spam filter.  I understand that everyone has a different view of what
requires discussion. From my experience with maintaining old code bases,
my view is that any change that runs afoul of "if it ain't broke don't
fix it" and risks invoking the law of unintended consequences should be
discussed.

>I agree that making changes to mainline code behaviour should not be
>done without a JIRA, and in some cases a dev discussion is also
>needed, but I don't think it's necessary to discuss every change on
>the dev list.

I don't think it's necessary to discuss every change on the dev list
either.  I may be wrong, but it seems like we've gotten to a point where
we're not discussing any code changes at all (only release bikeshedding)
or what the goals should be for future development and releases.  What
concerns me more is all of the drive-by contributions we've accepted.
People contribute significant chunks of code via patch or attachment
and disappear.  Even when we've voted them in as committers, like the
person who did the telnet extended commands (if I remember correctly),
we never hear from them again.  What's going to happen with the IMAP
contributor?  Can we recruit him as a committer?  How can we rebuild
the developer community?  Those are all rhetorical questions and don't
require answers.

daniel


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org