Xymon, community, updates, and directions (was Re: Is this thing on?)

list Japheth Cleaver
Thu, 17 Aug 2023 11:04:37 -0700
Message-Id: <user-da6d23e73a26@xymon.invalid>

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 :

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 <user-ce4a2c883f75@xymon.invalid>
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: <user-fe3dd6b83dab@xymon.invalid>
References: <user-e074871a01b3@xymon.invalid>
Cc: Xymon at xymon.com
In-Reply-To: <user-e074871a01b3@xymon.invalid>
To: "J.C. Cleaver" <user-87556346d4af@xymon.invalid>
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