Xymon, community, updates, and directions (was Re: Is this thing on?)
Le Tue, Aug 15, 2023 at 07:42:47AM +0100, Henrik St?rner via Xymon a ?crit :
Return-Path: <henrik at hswn.dk> X-Virus-Scanned: Debian amavisd-new at mx.hswn.dk DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hswn.dk; s=mail; t=1692081779; bh=6F8mAvlRTRvCdysuFXnx0ce1H/hOkoTfydrY+Jc40Pg=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=WwOVVcRxDvtUyEtqlB8j5yb4A+xBV3PmjPx6FFgmvAmDjArK2QtUEUlRhBUjjZRoW 1Miz8QewOvFvsDCK2+/IxUrH9SGuFyK12p8Otdp32w3LgNWnJKzAmxfox96SL4jT0S A2qPmlOUhqrVdpRNbXSnycKQIqaSXZ4HgLmkiS2s= Received: from smtpclient.apple (unknown [213.141.9.206]) by vmail.hswn.dk (Postfix) with ESMTPSA id 058E54413E; Tue, 15 Aug 2023 08:42:58 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Henrik St?rner <henrik at hswn.dk> Mime-Version: 1.0 (1.0) Subject: Re: [Xymon] Xymon, community, updates, and directions (was Re: Is this thing on?) Date: Tue, 15 Aug 2023 07:42:47 +0100 Message-Id: <5DA03C31-0A8C-4786-8128-2538DE97647E at hswn.dk> References: <0aa616fe51b5560fad8e4c01c54b7455.squirrel at mail.kkytbs.net> Cc: Xymon at xymon.com In-Reply-To: <0aa616fe51b5560fad8e4c01c54b7455.squirrel at mail.kkytbs.net> To: "J.C. Cleaver" <cleaver at terabithia.org> X-Mailer: iPad Mail (20G75)
Hi,
it seems this ?Is Xymon dead?? thread pops up from time to time. Which is understandable, given the lack of new releases and development work.
If someone would like to pick it up and dust it off in a major way, then I would suggest moving away from C as the primary language. Python would probably have a lot more potential developers. Also consider replacing the proprietary Xymon protocol with a REST API instead - then you could use standard http modules to talk to Xymon. Look at what each tool does, and reimplement it in a more modern way.
Hello
I agree on using a different language, xymon is basicly just string handling and C is dangerous with that. I am happy you thinked about python, because my try to redo xymon was in python and I think no other language could have permitted to reimplement so many part so fast and easily. But for me, the xymon protocol should be kept, it is easy parsable and do not need extra dependencies to be parsable. At least for the client protocol, having a client so easy to implement is a great advantage. For example, I could put a fake xymon client on some embedded boards (like ESP8266 and co)
But that requires more than one enthusiastic developer.
Although I do lurk on the mailing list occasionally, like JC I no longer have all of the codebase engrained in my brain. And my use of Xymon is strictly personal. So I won?t be able to contribute much.
And yes, the mailing list needs a new home soon.
If nobody want to do it, I could try to install a mailman on my personnal server. The list is so low traffic that should not be a problem.
Thanks for you work Regards
On Tue, August 15, 2023 13:18, Corentin Labbe wrote:
Le Tue, Aug 15, 2023 at 07:42:47AM +0100, Henrik St??rner via Xymon a ??crit :
Return-Path: <henrik at hswn.dk> X-Virus-Scanned: Debian amavisd-new at mx.hswn.dk DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hswn.dk; s=mail; t=1692081779; bh=6F8mAvlRTRvCdysuFXnx0ce1H/hOkoTfydrY+Jc40Pg=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=WwOVVcRxDvtUyEtqlB8j5yb4A+xBV3PmjPx6FFgmvAmDjArK2QtUEUlRhBUjjZRoW 1Miz8QewOvFvsDCK2+/IxUrH9SGuFyK12p8Otdp32w3LgNWnJKzAmxfox96SL4jT0S A2qPmlOUhqrVdpRNbXSnycKQIqaSXZ4HgLmkiS2s= Received: from smtpclient.apple (unknown [213.141.9.206]) by vmail.hswn.dk (Postfix) with ESMTPSA id 058E54413E; Tue, 15 Aug 2023 08:42:58 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Henrik St??rner <henrik at hswn.dk> Mime-Version: 1.0 (1.0) Subject: Re: [Xymon] Xymon, community, updates, and directions (was Re: Is this thing on?) Date: Tue, 15 Aug 2023 07:42:47 +0100 Message-Id: <5DA03C31-0A8C-4786-8128-2538DE97647E at hswn.dk> References: <0aa616fe51b5560fad8e4c01c54b7455.squirrel at mail.kkytbs.net> Cc: Xymon at xymon.com In-Reply-To: <0aa616fe51b5560fad8e4c01c54b7455.squirrel at mail.kkytbs.net> To: "J.C. Cleaver" <cleaver at terabithia.org> X-Mailer: iPad Mail (20G75)
Hi,
it seems this ???Is Xymon dead???? thread pops up from time to time. Which is understandable, given the lack of new releases and development work.
If someone would like to pick it up and dust it off in a major way, then I would suggest moving away from C as the primary language. Python would probably have a lot more potential developers. Also consider replacing the proprietary Xymon protocol with a REST API instead - then you could use standard http modules to talk to Xymon. Look at what each tool does, and reimplement it in a more modern way.
Hello
I agree on using a different language, xymon is basicly just string handling and C is dangerous with that. I am happy you thinked about python, because my try to redo xymon was in python and I think no other language could have permitted to reimplement so many part so fast and easily. But for me, the xymon protocol should be kept, it is easy parsable and do not need extra dependencies to be parsable. At least for the client protocol, having a client so easy to implement is a great advantage. For example, I could put a fake xymon client on some embedded boards (like ESP8266 and co)
I agree that with it mostly being string handling, which does raise plenty of options for other interpretations. And the text-based nature of the protocol allows for interoperability to be maintained. One of the beauties of xymon as currently architected is that there are essentially no performance-sensitive areas that require a fork in the central server, which puts a lot of the objection to interpreted languages to the side, if it only need to be launched once. (I'd considered a perl version of the server at one point, but python would be a solid case now.)
Along with string manipulation, memory management is pretty key as well, especially at scale. It's both a strength and a weakness here, but it suggests that "safer C" (a/k/a Rust) might also be an option.
I don't think either of these would be happening any time soon, however, and I agree that the TCP protocol as used is pretty easy to implement, minus the one-sided closure to signal a complete message that you're expecting a response back from.
Regards, -jc
participants (2)
-
clabbe.montjoie＠gmail.com
-
cleaver＠terabithia.org