Dear n.s.nntp,

Are there still extant C libraries that implement NNTP, and are
useful for creating Usenet clients?

I am aware of UW's c-client, currently hidden inside Alpine sources,
but I have not found it to be a really useful framework for building
my own news reader.

My question is really twofold.

1) Is there a library that already does this and can be used with SSL?

2) In the absence of 1) how would I start experimenting on my own?

Other than setting up my own INN in a virtual machine, I do not know
how to "practice" my own client. Do Usenet providers frown upon
practice clients, such as Eternal September?

And even with my own INN in a VM, I'm still not sure how to go about
practicing all the intricacies of SSL verification, without a publicly
available news server [possibly my own] and something like letsencrypt.

Am I perhaps overthinking this, and this is rather easy?
--
Johann | email: invalid -> com | www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | twitter: @myrkraverk

On Sep 5, 2023 at 10:06:46 AM CDT, "Johann 'Myrkraverk' Oskarsson"
<johann@myrkraverk.invalid> wrote:

> Other than setting up my own INN in a virtual machine, I do not know
> how to "practice" my own client. Do Usenet providers frown upon
> practice clients, such as Eternal September?

You're welcome to experiment with NNTP commands and clients using my server
(news.blueworldhosting.com).

I don't think Usenet clients identify themselves through NNTP commands, some
may add headers to messages they compose, but I don't believe the protocol
specification has anything for identifying clients like the HTTP User Agent.

On 05.09.23 17:06, Johann 'Myrkraverk' Oskarsson wrote:
> Are there still extant C libraries that implement NNTP
I'm not a C guy but as C is old as nntp i bet you'll find something?

> and are useful for creating Usenet clients?
What kind of client?
a reader or a binary downloader?

> 1) how would I start experimenting on my own?

https://datatracker.ietf.org/doc/html/rfc3977

> Do Usenet providers frown upon practice clients, such as Eternal
September?

Paid providers mostly don't care. private ones may do better in banning
you for doing stupid stuff.
please try only with your localhost. inn is enough.

> practicing all the intricacies of SSL verification

SSL(-lib) is only a wrapped around layer to a tcp connection which in
case of NNTP sends/receives commands and data via text or
'line1\r\nline2\r\n.'

why use C?
try GO and have a working ssl/tcp connection with a textproto wrapper

easy like this:

the returned 'srvtp *textproto.Conn': https://pkg.go.dev/net/textproto

the returnd 'conn net.Conn' is either the tcp or ssl conn which can be
closed via conn.Close() -> https://pkg.go.dev/net#Conn .

import (
"crypto/tls"
"net"
"net/textproto"
)

type PEER struct {
Hostname string
Port int
Addr4 string
Addr6 string
R_SSL bool
R_SSL_Insecure bool
} // end type PEER

func main() {
peer := &PEER{
Hostname: "myServer",
Addr4: "localhost",
Port: 119, R_SSL: true
}
srvtp, rconn, err := RCONN(1, 1, peer)
if err != nil {
log.Printf("Error RCONN err='%v'", err)
return
}
for {
line, err := s.srvtp.ReadLine()
if err != nil {
log.Printf("Error ReadLine err='%v'", err)
return false
}
log.Printf("srvtp.Readline='%s'", line)
}
}

func RCONN(num int, wid int, peer *PEER) (*textproto.Conn, net.Conn,
error) {
log.Printf("New RCONN num=%d wid=%d peer=%s", num, wid, peer.Hostname)
var conn net.Conn
var err error
ssl_conf := &tls.Config{
InsecureSkipVerify: true,
}
addrs := []string{peer.Hostname, peer.Addr4, peer.Addr6}
port := 119
if peer.Port > 0 && peer.Port < 65535 {
port = peer.Port
}
connect_peer:
for _, addr := range addrs {
if addr == "" {
continue connect_peer
}

peer_url := fmt.Sprintf("peer.Hostname:%d", port)
if peer.R_SSL {
conn, err = tls.Dial(peer_url, "tcp", ssl_conf)
} else {
conn, err = net.Dial(peer_url, "tcp")
}
if err != nil {
log.Printf("ERROR CONN Dial peer=%s peer_url='%s' err='%v'",
peer.Hostname, peer_url, err)
time.Sleep(time.Second * 3)
continue connect_peer
}
break connect_peer
} // end for loop_connect
if conn == nil || err != nil {
return nil, nil, fmt.Errorf("ERROR CONN conn=nil peer=%s err='%v'",
peer.Hostname, err)
}
srvtp := textproto.NewConn(conn)
code, msg, err := srvtp.ReadCodeLine(20)
if err != nil || (code != 200 && code != 201) {
log.Printf("ERROR RCONN code=%d msg='%s' peer=%s err='%v'", code, msg,
peer.Hostname, err)
return nil, nil, err
}
log.Printf("RCONN ESTABLISHED peer=%s", peer.Hostname)
return srvtp, conn, err
} // end func RCONN

MIT license.

On Sep 5, 2023 at 10:06:46 AM CDT, "Johann 'Myrkraverk' Oskarsson"
<johann@myrkraverk.invalid> wrote:

> Dear n.s.nntp,
>
> Are there still extant C libraries that implement NNTP, and are
> useful for creating Usenet clients?
>
> I am aware of UW's c-client, currently hidden inside Alpine sources,
> but I have not found it to be a really useful framework for building
> my own news reader.
>
> My question is really twofold.
>
> 1) Is there a library that already does this and can be used with SSL?
>
> 2) In the absence of 1) how would I start experimenting on my own?
>
> Other than setting up my own INN in a virtual machine, I do not know
> how to "practice" my own client. Do Usenet providers frown upon
> practice clients, such as Eternal September?
>
> And even with my own INN in a VM, I'm still not sure how to go about
> practicing all the intricacies of SSL verification, without a publicly
> available news server [possibly my own] and something like letsencrypt.
>
> Am I perhaps overthinking this, and this is rather easy?

Not a developer, but did some looking around and found that libwww by W3C
contains a NNTP implementation that may be useful:

https://www.w3.org/Library/src/WWWNews.html

You can find the original NNTP 'reference implementation' sources at:

ftp://ftp.dinoex.org/pub/c-news/nntp.1.5.12.2.tar.gz
or
http://mirror.its.dal.ca/freebsd/distfiles/nntp.1.5.12.2.tar.gz

(don't forget the Y2k patch)
http://mirror.its.dal.ca/freebsd/distfiles/nntp-patch-y2k

On 9/6/2023 3:42 AM, Jesse Rehmer wrote:
> On Sep 5, 2023 at 10:06:46 AM CDT, "Johann 'Myrkraverk' Oskarsson"
> <johann@myrkraverk.invalid> wrote:
>
>> Other than setting up my own INN in a virtual machine, I do not know
>> how to "practice" my own client. Do Usenet providers frown upon
>> practice clients, such as Eternal September?
>
> You're welcome to experiment with NNTP commands and clients using my server
> (news.blueworldhosting.com).
>
> I don't think Usenet clients identify themselves through NNTP commands, some
> may add headers to messages they compose, but I don't believe the protocol
> specification has anything for identifying clients like the HTTP User Agent.

Thank you. I'm still working on the GUI, and this is not a high
priority project, so it may end up being a few months until I'm ready
to try real world testing.

I'll probably give a heads up as a courtesy when I start.

--
Johann | email: invalid -> com | www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | twitter: @myrkraverk

On 9/6/2023 5:01 AM, Billy G. (go-while) wrote:
> On 05.09.23 17:06, Johann 'Myrkraverk' Oskarsson wrote:
>> Are there still extant C libraries that implement NNTP
> I'm not a C guy but as C is old as nntp i bet you'll find something?

Yup, what I originally found, c-client from University of Washington
didn't turn out to be as "user friendly" as I was expecting, so I'm
looking around.
>
>> and are useful for creating Usenet clients?
> What kind of client?
> a reader or a binary downloader?

Primary purpose is a reader, but binary downloader as well, as long
as it's not a conflict of purpose.

>
> > 1) how would I start experimenting on my own?
>
> https://datatracker.ietf.org/doc/html/rfc3977
>
> > Do Usenet providers frown upon practice clients, such as Eternal
> September?
>
> Paid providers mostly don't care. private ones may do better in banning
> you for doing stupid stuff.
> please try only with your localhost. inn is enough.

That's good to know, and I'll certainly keep it in mind.

>
> > practicing all the intricacies of SSL verification
>
> SSL(-lib) is only a wrapped around layer to a tcp connection which in
> case of NNTP sends/receives commands and data via text or
> 'line1\r\nline2\r\n.'
>
> why use C?

The reason I want to use C, is to build something that potentially can
work for everyone, including VAX/VMS, [MS|PC|Free]DOS, Amiga -- or the
more modern Vampire -- as well as the current operating systems we use
from day to day in the real world, far into the future.

For people who don't have that concern, other programming languages are
a good choice, and I'd probably go with Common Lisp, or OCaml, if that
wasn't my desired social contract.

Best of luck with Go.

[snip]

--
Johann | email: invalid -> com | www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | twitter: @myrkraverk

On 9/6/2023 5:59 AM, Jesse Rehmer wrote:
> On Sep 5, 2023 at 10:06:46 AM CDT, "Johann 'Myrkraverk' Oskarsson"
> <johann@myrkraverk.invalid> wrote:
>
>> Dear n.s.nntp,
>>
>> Are there still extant C libraries that implement NNTP, and are
>> useful for creating Usenet clients?
>>
>> I am aware of UW's c-client, currently hidden inside Alpine sources,
>> but I have not found it to be a really useful framework for building
>> my own news reader.
>>
>> My question is really twofold.
>>
>> 1) Is there a library that already does this and can be used with SSL?
>>
>> 2) In the absence of 1) how would I start experimenting on my own?
>>
>> Other than setting up my own INN in a virtual machine, I do not know
>> how to "practice" my own client. Do Usenet providers frown upon
>> practice clients, such as Eternal September?
>>
>> And even with my own INN in a VM, I'm still not sure how to go about
>> practicing all the intricacies of SSL verification, without a publicly
>> available news server [possibly my own] and something like letsencrypt.
>>
>> Am I perhaps overthinking this, and this is rather easy?
>
> Not a developer, but did some looking around and found that libwww by W3C
> contains a NNTP implementation that may be useful:
>
> https://www.w3.org/Library/src/WWWNews.html
>
> You can find the original NNTP 'reference implementation' sources at:
>
> ftp://ftp.dinoex.org/pub/c-news/nntp.1.5.12.2.tar.gz
> or
> http://mirror.its.dal.ca/freebsd/distfiles/nntp.1.5.12.2.tar.gz
>
> (don't forget the Y2k patch)
> http://mirror.its.dal.ca/freebsd/distfiles/nntp-patch-y2k

Thank you, that seems extremely useful, if only to learn from the code
before I implement my own.

--
Johann | email: invalid -> com | www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | twitter: @myrkraverk

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:

> The reason I want to use C, is to build something that potentially can
> work for everyone, including VAX/VMS, [MS|PC|Free]DOS, Amiga -- or the
> more modern Vampire -- as well as the current operating systems we use
> from day to day in the real world, far into the future.

Writing portable C that will work on all of those platforms will be a
significant challenge, particularly for the NNTP protocol which requires
dealing with the networking stack, which in turn is quite different across
that spectrum of operating systems if I recall correctly.

Given that portability desire, you're probably better off writing your
client in Python, since other folks have done the Python porting work for
you.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

Russ Allbery <eagle@eyrie.org> wrote:
> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
>
>> The reason I want to use C, is to build something that potentially can
>> work for everyone, including VAX/VMS, [MS|PC|Free]DOS, Amiga -- or the
>> more modern Vampire -- as well as the current operating systems we use
>> from day to day in the real world, far into the future.
>
> Writing portable C that will work on all of those platforms will be a
> significant challenge, particularly for the NNTP protocol which requires
> dealing with the networking stack, which in turn is quite different across
> that spectrum of operating systems if I recall correctly.
>
> Given that portability desire, you're probably better off writing your
> client in Python, since other folks have done the Python porting work for
> you.

You're joking right? I avoid Python scripts on _Linux_ because they
rarely work with the version I'm running (whether that's too new,
or too old). Good luck on more obscure platforms!

There are plenty of cross-platform programs that use networking,
written in C. From the X window system to this lightweight
encryption library (perhaps useful to the OP if they're interested
in NNTPS?):
https://github.com/classilla/cryanc

That said, it would be quite a challenge, but Python is far from
the solution there.

--
__ __
#_ < |\| |< _#

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
> On 9/6/2023 5:59 AM, Jesse Rehmer wrote:
>> Not a developer, but did some looking around and found that libwww by W3C
>> contains a NNTP implementation that may be useful:
>>
>> https://www.w3.org/Library/src/WWWNews.html
>>
>> You can find the original NNTP 'reference implementation' sources at:
>>
>> ftp://ftp.dinoex.org/pub/c-news/nntp.1.5.12.2.tar.gz
>> or
>> http://mirror.its.dal.ca/freebsd/distfiles/nntp.1.5.12.2.tar.gz
>>
>> (don't forget the Y2k patch)
>> http://mirror.its.dal.ca/freebsd/distfiles/nntp-patch-y2k
>
> Thank you, that seems extremely useful, if only to learn from the code
> before I implement my own.

Libwww was apparantly the basis for Lynx (web browser with NNTP
support), which seems to include a more recent version of the code
in the "WWW" directory of its source code.

https://lynx.invisible-island.net/
https://github.com/ThomasDickey/lynx-snapshots

--
__ __
#_ < |\| |< _#

not@telling.you.invalid (Computer Nerd Kev) writes:

> There are plenty of cross-platform programs that use networking, written
> in C. From the X window system to this lightweight encryption library
> (perhaps useful to the OP if they're interested in NNTPS?):
> https://github.com/classilla/cryanc

Which, as noted on that page, doesn't work on VMS.

I think you are significantly underestimating how much of a challenge
getting portable C to run on the list of platforms given in the original
message is. That list is not just obscure UNIX platforms, which would be
relatively straightforward. It includes platforms that the typical helper
software like Autoconf won't touch.

There is a Python port to VMS already, for example, which supports the
standard Python language. (It's even fairly recent; Python 3.10, I
believe.) That port is already dealing with a rather large amount of
stuff that you would otherwise have to handle manually.

I know any mention of Python for some reason lights some people's hair on
fire, but I mentioned it specifically because it's one of the most ported
languages, thanks in part to somewhat-reduced implementations that run on
all sorts of really obscure platforms. You may well have to stick to a
very carefully chosen subset of Python for your program to work
everywhere, but it's still going to be less work than starting at the C
level and trying to figure out even how to successfully invoke a compiler
on some of those systems.

Far be it from me to discourage anyone else's hobbies, but if your hobby
is writing a portable NNTP library for that range of platforms in C, your
hobby is actually porting C to obscure platforms. The NNTP stuff is going
to be a very tiny part of the project. :)

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

On 9/7/2023 9:51 AM, Russ Allbery wrote:
[snip]

> Far be it from me to discourage anyone else's hobbies, but if your hobby
> is writing a portable NNTP library for that range of platforms in C, your
> hobby is actually porting C to obscure platforms. The NNTP stuff is going
> to be a very tiny part of the project. :)

I believe you're vastly overestimating the effort of writing portable C
network code. C network libraries exist for this purpose, the two I can
name at the top of my head are NSPR and SDL_net. The former is still
used by Firefox, and at one time worked on RISC OS too. I off hand
don't recall if it worked on VMS before.

There are also ways to write the NNTP code in a way that can be plugged
into any networking framework. Such techniques are discussed in the
/Patterns in C/ book by Tornhill, though of course that'll end up as
"callback hell" as some people put it.

Anyway, at a certain competency level, the portability of the code just
stops being a concern. Either because it's written flexibly enough,
with techniques as described by Tornhill [1] or even /that OOP book/
from 199x, IIRC, which I currently forgot the name of; or because the
NNTP is written for a particular cross platform library, NSPR, SDL_net,
or something else, that then isn't hard to port to new [or old]
platforms.

A lot of experience, and a little bit of thinking ahead goes a long way.

[1] I didn't learn all these techniques from that book, but it's a
useful reference for discussions like this.

--
Johann | email: invalid -> com | www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | twitter: @myrkraverk

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:

> I believe you're vastly overestimating the effort of writing portable C
> network code. C network libraries exist for this purpose, the two I can
> name at the top of my head are NSPR and SDL_net. The former is still
> used by Firefox, and at one time worked on RISC OS too. I off hand
> don't recall if it worked on VMS before.

NSPR was ported to OpenVMS once, in the sense that an OpenVMS developer
got it to build but no one else was able to reproduce that, more than ten
years ago. It almost certainly no longer works there.

Anyway, it's probably pointless to argue about this. I said my piece
based on my own experience with maintaining portable C code, which is
worth exactly what you paid for it. I gave the warning that I would have
appreciated at various points in my own past; whether that's useful to
anyone else is entirely up to them. Far be it from me to discourage other
people's quixotic hobbies; I have a large collection of my own.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

On 9/8/2023 1:10 AM, Russ Allbery wrote:
> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
>
>> I believe you're vastly overestimating the effort of writing portable C
>> network code. C network libraries exist for this purpose, the two I can
>> name at the top of my head are NSPR and SDL_net. The former is still
>> used by Firefox, and at one time worked on RISC OS too. I off hand
>> don't recall if it worked on VMS before.
>
> NSPR was ported to OpenVMS once, in the sense that an OpenVMS developer
> got it to build but no one else was able to reproduce that, more than ten
> years ago. It almost certainly no longer works there.
>
> Anyway, it's probably pointless to argue about this. I said my piece
> based on my own experience with maintaining portable C code, which is
> worth exactly what you paid for it. I gave the warning that I would have
> appreciated at various points in my own past; whether that's useful to
> anyone else is entirely up to them. Far be it from me to discourage other
> people's quixotic hobbies; I have a large collection of my own.
>

Fair enough, and yes, I have my weird hobbies. Writing portable C code
is an art, and sometimes quite frustrating.

On the subject of Python, I fear, based on my own experience and others'
that it isn't the panacea [some people|you] think it is. Mostly, what
frustrates people these days is that tested and working code isn't work-
ing anymore, because it isn't pythonic enough two to five years later.
Personally, that's enough for me to stay away from that particular side
of the tech spectrum.

Anyway, I'll report back when I've gotten somewhere with my NNTP adven-
tures. Thanks to everyone who replied in the thread,

--
Johann | email: invalid -> com | www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | twitter: @myrkraverk

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:

> On the subject of Python, I fear, based on my own experience and others'
> that it isn't the panacea [some people|you] think it is. Mostly, what
> frustrates people these days is that tested and working code isn't work-
> ing anymore, because it isn't pythonic enough two to five years
> later.

This is also quite famously true of C code due to increasingly aggressive
optimization passes that depend more on the formal semantics of C that are
often not followed by real-world code. Linus Torvalds complains about it
all the time. (There of course are good arguments about which language is
more vulnerable to this, and to some extent it depends on what you're
doing in the language. Certainly the Python 3 transition was a huge,
disruptive change unlike anything that C has gone through; the transition
from K&R to ISO C took place over a much longer period of time and to this
day isn't entirely complete in that some C compilers still accept K&R
code, although that support seems to be dropping off.)

I think ongoing maintenance is just part of writing code, but I do seem to
be more sanguine about this than many people.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

On 2023-09-07, Russ Allbery <eagle@eyrie.org> wrote:
> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
>> On the subject of Python, I fear, based on my own experience and others'
>> that it isn't the panacea [some people|you] think it is. Mostly, what
>> frustrates people these days is that tested and working code isn't work-
>> ing anymore, because it isn't pythonic enough two to five years
>> later.
>
> This is also quite famously true of C code due to increasingly aggressive
> optimization passes that depend more on the formal semantics of C that are
> often not followed by real-world code. Linus Torvalds complains about it
> all the time. (There of course are good arguments about which language is
> more vulnerable to this, and to some extent it depends on what you're
> doing in the language. Certainly the Python 3 transition was a huge,
> disruptive change unlike anything that C has gone through;

You are absolutely right, but the Python 3 transition happened fifteen
years ago now. The claim above that things have massively changed to
break working code in the last "two to five years" is ... difficult to
reconcile with reality.

Jon Ribbens <jon+usenet@unequivocal.eu> writes:

> You are absolutely right, but the Python 3 transition happened fifteen
> years ago now. The claim above that things have massively changed to
> break working code in the last "two to five years" is ... difficult to
> reconcile with reality.

I tend to give people the benefit of the doubt on this because it does
depend on what you're doing with the language. I personally seem to have
very good luck; both my Python code and my C code seems to rarely be
affected by this stuff. (But I love language trivia and am usually
familiar with deprecations and "native style" for lack of a better term.)

Python has a fairly regular stream of deprecation warnings, and sometimes
breaking changes in libraries (and whole deprecated libraries), so you can
get unlucky and have a lot of mandatory updates if you happened to pick
the wrong stuff. I'm a bit more dubious at the core language level, but
Python by design blurs those lines (the whole "batteries included" thing),
and I also use linters fairly aggressively (Ruff is great) which may
explain why I got steered away from stuff that was unstable or potentially
deprecated.

But yes, outside of this thread (for which I have no data), a lot of the
people I see on-line who are mad about Python portability are still mad
about the Python 3 transition, and so far as I can tell are determined to
stay mad about it until they die.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

Hi Russ,

> I personally seem to have
> very good luck; both my Python code and my C code seems to rarely be
> affected by this stuff.

Same thing for me as for the Python scripts and the web site in Python
(using mod_wsgi) I wrote. The transition to Python 3 was easy. The
only problem I ran into was to properly handle the literal strings that
are taken as Unicode code points by default, contrary to Python 2. Once
that mechanism is understood, decoding/encoding at the right places is easy.

--
Julien ÉLIE

« It's documented in The Book, somewhere… » (Larry Wall)

Julien ÉLIE <iulius@nom-de-mon-site.com.invalid> writes:
> Hi Russ,
>
>> I personally seem to have very good luck; both my Python code and my
>> C code seems to rarely be affected by this stuff.
>
> Same thing for me as for the Python scripts and the web site in Python
> (using mod_wsgi) I wrote. The transition to Python 3 was easy. The
> only problem I ran into was to properly handle the literal strings
> that are taken as Unicode code points by default, contrary to Python
> 2. Once that mechanism is understood, decoding/encoding at the right
> places is easy.

The C API changed a fair bit, with some things going away completely and
needing to be replaced. i.e extension module authors had a bit more work
to do than people working in pure Python.

--
https://www.greenend.org.uk/rjk/

Hi Richard,

>> Same thing for me as for the Python scripts and the web site in Python
>> (using mod_wsgi) I wrote. The transition to Python 3 was easy. The
>> only problem I ran into was to properly handle the literal strings
>> that are taken as Unicode code points by default, contrary to Python
>> 2. Once that mechanism is understood, decoding/encoding at the right
>> places is easy.
>
> The C API changed a fair bit, with some things going away completely and
> needing to be replaced. i.e extension module authors had a bit more work
> to do than people working in pure Python.

Indeed, it's far more work with the C API.
I remember having added Python 3 support in INN a few years ago, and it
was a bit of work, essentially for memoryview handling and Unicode:
https://github.com/InterNetNews/inn/commit/f99cc6a4193b5ac75c0453c769bbc7c905d33015

I totally agree that for extension modules in general, the switch is
complicated (INN does not use much of available Python C API).

--
Julien ÉLIE

« The best preparation for tomorrow is to do today's work superbly
well. » (William Osler)

For your reference, records indicate that
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:

> Dear n.s.nntp,
>
> Are there still extant C libraries that implement NNTP, and are
> useful for creating Usenet clients?

Honestly, no. I started working on a Mac newsreader back in 2014 when
MT-NewsWatcher was broken by a system update. I did a survey of all
the open source C-based NNTP clients I could find, in hopes that one
of them would be easy to wrap Objective-C around.

What I found is that most projects got “opinionated” very quickly, and
the required dependencies were forcing me to focus on things that had
nothing to do with NNTP. Given that the protocol isn’t that complex,
it was easier for me to implement my objects from scratch (using Apple’s
supplied NSStream objects to take care of SSL and all the other lower
level network stuff).

> 2) In the absence of 1) how would I start experimenting on my own?

Again, since the protocol isn’t that complex, you’re not likely to run
into all that much trouble with public servers as long as you don’t let
your buggy code flood them. Take it in small steps and your traffic
won’t even be a blip on the radar, even given the low Usenet usage these
days.

> Am I perhaps overthinking this, and this is rather easy?

It’s “easy” in the sense that if you have the skills to write the
software in the first place, the NNTP protocol itself is not going to
give you difficulty. What I spent the bulk of my time on was everything
that happens before and after the data transfer. Heaven help you if
you’re looking to make something with multipart binary support . . .

--
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly

Doc O'Leary , <droleary.usenet@2023.impossiblystupid.com> writes:

> It’s “easy” in the sense that if you have the skills to write the
> software in the first place, the NNTP protocol itself is not going to
> give you difficulty. What I spent the bulk of my time on was everything
> that happens before and after the data transfer. Heaven help you if
> you’re looking to make something with multipart binary support . . .

Yeah, agreed, the NNTP part is drastically simpler than the article
parsing part. Even if you don't implement MIME, parsing news articles is
challenging. There are a lot of libraries out there, but my impression is
that there are more of them in higher-level languages like Perl or Python
than there are in C (probably for the obvious reason that it's essentially
all string parsing, which is one of C's weakest points since the language
exposes all of the fiddly bits and byte counting and provides you very
little help with character sets).

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.