I'll jump in since I wrote the other filters that aren't in C...
November 13, 2019 7:04 AM, "Martijn van Duren" <openbsd+po...@list.imperialat.at> wrote: > [...] > > I do however dislike the trend that every single filters in ports not > written by me is in go. At first I thought this was to display the > flexibility of the smtpd-api (I even recollect it was said, but I can't > find the mail which states so). But it's restricting to OpenBSD users > not running on amd64, arm, or i386. > I was the one who said I'd write filters in !C to show that the stdin/stdout-based API was not tied to a specific language, and I didn't know this implied I could only use them in experiments but not to do actual useful things. Your comment that it is restricting is a bit off. What would be restricting is if I did not write them so that no OpenBSD users on any architecture would be able to use them. It is unfortunate that these features are not available to more but the cost of writing them in C was considerably higher and I might not have found time to write them at all. You are free to provide a portable replacement if this bothers you so much that these tools even exist in the first place. > Just yesterday there was someone who couldn't run a filter on sparc64 > because it was written in go[0]. If we as OpenBSD community value > portability over architectures these tools should be written in a > language that's just as portable. > Because I spend time writing something in a language does not mean that I'm willing to spend more time writing it in another. Even if written by me, Joerg, or whoever, these tools are _third-party_ addons written by individuals who worked on their own use-cases. I have no idea what Joerg did with his filter, it is not in OpenSMTPD and I've no use for Amavis. Eric probably did not look at my filter-senderscore, I doubt he is using it, others do. They're not in any OpenBSD/OpenSMTPD roadmap whatsoever and filter-rspamd exists only because I was bored on a week-end and motivated enough to start writing it. They are not shipped in base, they are not shipped with OpenSMTPD, they are not even in the portable repository, they are individual work. That you think this work should be done in a language is your opinion but as long as it's not in base and not even in the portable OpenSMTPD release I don't see why the language used for these is even to be debated. Yes, it would be better if sparc64 users could use them, so when you're bored on a week-end, write a replacement in C. > If you want to demonstrate the flexibility of the API write it in > something new like ruby, C++, or even PHP or awk for all I care. > If you care about portability please use one of these (although > PHP is currently not supported on HPPA). > No, sorry, but no. If I'm working on a side-project during my free time, you don't get to decide how I'm working on it. I'll write it in fucking brainfuck or asm if that's what I want to waste my spare time with. I picked Go because I wanted to see what made it so popular, I made SEVERAL projects with it and TWO of them are filters for which I've submitted packages as I thought that it was a nice thing to do. Goroutines and channels makes Go a pleasant choice to write filters so, wether you like it or not, I'll keep using it to handle MY very own use-cases until I find a better tool. If such tools are not wanted in ports, porters can just tell me and I'll stop packaging them with no hard feelings. > Maybe you could give libopensmtpd a go (pun intended). I reckon > it's not hard to use. > Because I spend time writing something in a language does not mean that I'm willing to write it in another. Some filters I write in C, others I don't. libopensmtpd as of today may be portable to multiple archs but it isn't portable to other systems so if I use it today, I can write filters for OpenBSD/sparc64 but no longer for Linux, FreeBSD or OSX. The fact that I can write filters portable to other systems today means that a much larger community of users is now reporting bugs, and caused three bugs to be fixed in CVS. Had I not written these filters in Go we would not have had these reports. If you want more coverage, write alternatives.
