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

[J.C. Cleaver]

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