I feel bad for barging in here
Hello and welcome! Don't feel bad for joining in the conversation, it's welcome. Have some opinions that you may or may not find useful:
I don't know about A2Server but I know that macipgw is being actively updated, as you can tell from
@mactjaap's involvement upthread. There are regular updates on the various macipgw projects on these forums.
I don't believe there are problems with DDP on the Pi 4 as such, but there was quite a long period where DDP in the Linux kernel was broken, and it's still not what I'd consider a really reliable feature. Which is fair enough, it's hardly their priority. But netatalk2 is reliant on the underlying OS to provide basic DDP support, and if the DDP support is broken, netatalk2 won't run.
Personally, I run netatalk2 on top of NetBSD, as I'm sure people are tired of me banging on about. The DDP code in the kernel seems to be better maintained, and there's an actively maintained binary package that is tested and updated for new versions of NetBSD.
In terms of the logistics of keeping the codebase alive in an organised fashion, I know that
@slipperygrey is trying to roll all the bug fixes into one place and git repo and try to manage the codebase a bit, and I believe is trying to contribute them upstream to the "main" netatalk repository. I'm always grateful for people who are willing to do that kind of work for fun: it's far too much like what I do for work, so I can never muster the energy to do it myself. I also know that
@NJRoadfan has fixed multiple bugs in both netatalk2 generally and A2server more specifically, but I don't know how they organise their code or contribute it or whatever. The NetBSD package maintainer has also been around here intermittently sniffing out bug fixes.
Personally I just occasionally write stuff and fling it at whoever looks most like a project maintainer, I'm afraid!
In the really long term, I'm not convinced that netatalk2 is the right codebase to be building on. netatalk2 is a tool for big networks with complicated requirements, which is why its configuration has lots of switches and options, and why it needs finesseing on networks without a router. It's also fairly dense, fairly old-school C that is written to perform, rather than to be comprehensible or maintainable. So, while it was a good tool for corporate/largeish-network AppleTalk, it isn't really suitable for home use with a small handful of machines. That's not meant of course to argue that people who are doing logistics on keeping netatalk2 building and working are wasting their time, they're doing good work that I couldn't, and I appreciate them. But it'd also be nice to have a simpler, easier to maintain appletalk stack that perhaps didn't have all the features and performance for hobbyist use.
For the last two or three years I've been slowly trying to put together pieces for that kind of AppleTalk stack, though I don't know whether we'll ever get there or not. The two results of this project that are currently actually real are the LocalTalk over UDP support in Mini vMac, and the
AirTalk wireless dongle for classic macs (which isn't quite finished yet but I think it's fair to say is in late-stage beta testing). I'm kind of letting that project go where it wilt, because it's more interesting that way...