As part of a larger project that I have in mind, I'm looking for an
enhanced News::NNTPClient module.  I would like to make use of some
alternative connection methods, as follows:

--  A telnet-based connection method that does the following:

    (1) Performs a telnet shell login to a specified host given
        a user ID and password.

    (2) From there, invokes telnet on this remote host to connect
        to a specified NNTP server accessible from that host.

-- An rlogin-based connection method that does the following:

    (1) Performs an rlogin to a specified host given a user
        ID and password.

    (2) From there, invokes telnet on this remote host to connect
        to a specified NNTP server accessible from that host.

-- An rsh/ssh-based connection method that does the following:

    (1) Performs an rsh/ssh to a remote host running a telnet
        client on that host to connect to a specified NNTP server
        accessible from that host.

I know that the first two of these are feasible, since the Gnus
package (for FSF Emacs and XEmacs) successfully implements these
telnet and rlogin options in elisp.  I presume that my third
suggestion is also implementable.

Is anyone already working on something like this?  If not, then I'd be
willing to try to implement this myself, in which case, I'm looking
for comments and suggestions concerning the best approach for adding
these capabilities to News::NNTPClient.  Some options that occur to me
are ...

(A) Build a lower-level nntp-connection layer underneath News::NNTPClient
    which allows for pluggable connection modules (the default being
    standard NNTP as is done today).  I would then write the three
    new connection methods as pluggable modules.  These pluggable
    modules might be subclasses of something called, perhaps,
    News::NNTPConnection.

(B) Extend the hierarchy one level, as follows:

       News::NNTPClient::Std    (same as today's News::NNTPClient)
       News::NNTPClient::Telnet
       News::NNTPClient::Rlogin
       News::NNTPClient::Rsh

    The News::NNTPClient module would remain for backwards compatibility
    and would automatically invoke the News::NNTPClient::Std module.

(C) Organize it like this, instead:

       News::NNTPClient     (same as today)
       News::TelnetClient
       News::RloginClient
       News::RshClient

(D) Other ... ???

If I end up implementing this, another question I have that I'd like
people's feedback about concerns how I would actually manage the
Telnet/Rlogin/Rsh/Ssh connections.  What do you folks think about each
of these options? ...

(A) Use the fairly new Expect module.

(B) Use Net::Telnet.

(C) Use Comm.pl.

(D) Roll my own socket-based code.

(E) Other ... ???

Thanks in advance for your comments and feedback.

--
 Lloyd Zusman

 Lloyd> As part of a larger project that I have in mind, I'm looking
 Lloyd> for an enhanced News::NNTPClient module.  I would like to make
 Lloyd> use of some alternative connection methods, as follows:

 Lloyd> --  A telnet-based connection method that does the following:

Using telnet to pass non-telnet-based protocols is evil, evil, evil.

For a demonstration of why, try retrieving this article via telnet.
The presense of characters such as ?, or especially sequences like ?,
in a news article will do very unhealthy things.

 Lloyd> -- An rlogin-based connection method that does the following:

Likewise.

 Lloyd> -- An rsh/ssh-based connection method that does the following:

 Lloyd>     (1) Performs an rsh/ssh to a remote host running a telnet
 Lloyd>         client on that host to connect to a specified NNTP server
 Lloyd>         accessible from that host.

Again, once you have a telnet client handling a non-telnet-based
protocol, you are in trouble.

ssh can do some nifty things with tunnels, though.

 Lloyd> I know that the first two of these are feasible, since the
 Lloyd> Gnus package (for FSF Emacs and XEmacs) successfully
 Lloyd> implements these telnet and rlogin options in elisp.

Yeah, but it still blows up on articles like this one. (Depending on
the behaviour of the telnet client of course.)

--
Andrew.