commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel F. Savarese" <...@savarese.org>
Subject Re: [net]adding authentication to the NNTP class
Date Tue, 22 Apr 2003 17:49:54 GMT

In message <C9BADAB54BD3D3118B750050DA2BBD1009183D09@sxexch2.qgraph.com>, "Brek
ke, Jeff" writes:
>Please try to get mailing to the list worked out, there are other
>discussions about the NNTP stuff going on there that might be helpful.

I never got the original message.  It turns out I must have gotten spam
from eircom.net (either a real or forged relay) at some time because it
was in my mail server's bad domain list.  I just took it out.  Anyway,
Roy, yes, as Jeff said, please try to find a way to carry on the discussion
on commons-dev.

>> -----Original Message-----
>> From: Rory Winston [mailto:rwinston@eircom.net]

>> NNTP module as defined in RFC 2980. To this end, I have:
>> starters, could anyone give me any feedback on the approach I 
>> am taking? For
>> instance, does the username/password state belong in NNTP
>> or NNTPClient? I dont wish to inadvertantly undermine the 
>> architecture or
>> hierarchy of the module in any way. Here is a cvs diff of my changes:

For better or for worse, the way it works is that NNTP provides the
bare bones protocol communication and NNTPClient implements the slightly
higher-level operations, but not too high-level.  I'm not saying it's
the best way to have done it, but it's the way it works, so for the sake
of keeping the code consistent until such time a redesign dictates otherwise, 
I'll make the following comments.  NNTP should have a method for each NNTP
protocol command named after the protocol command.  So NNTP would normally
have an
 int authinfo(String)
method.  However, AUTHINFO is weird, so we can't do that, so we can
compromise and have:
 int authinfoUser(String)
 int authinfoPass(String)
Then NNTPClient can have
  int authenticate(String username, String password)
In general, the protocol clients do not save username and password
information, but that's because none of the protocols implemented as
of yet require it (authentication happens once up front).  An NNTPClient
subclass could keep track of authentication information and issue
AUTHINFO commands every time a server response requires it (perhaps
by overriding and wrapping sendCommand()), or re-establish
connections after the server times out the client for being idle to long.
Basically, the FOOClient classes aren't supposed to provide too much in the
way of convenience methods or state management and are supposed to be basic
building blocks for application libraries.  However, I think it's probably
a good idea if we start adding classes to Commons Net that do a lot of
convenient often required higher-level things and are more like
full-featured "beans" than raw protocol classes.  Maybe they should
go in a separate component or bean package, but that's a separate
discussion.

At any rate, everything you did is great, but for the sake of consistency
with the existing code, I'd recommend we rearrange it slightly as
described.

daniel



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


Mime
View raw message