Xymon Mailing List Archive search

Is this thing on? Update #2 Feedback

list Bruno Manzoni
Mon, 9 Oct 2023 07:37:49 +0200
Message-Id: <user-c6288df6b0d3@xymon.invalid>

Info from Jeezzaa incorporated to the PoC "problem solving", Jezzaaa invited as a member of the PoC.
Jeezzaa put some comments on some problems: I did not think about that: I like it: so feel free also to add yours: 1 comment per person would be perfect!
Remark: I did try to summary also each problems: to have a quick view of any problems: This is quite challenging to be non oriented: So expect some mistakes and clumsiness. Best would be that some of you help me doing that.

Thank you very very very much Jeezzaaa for the feedback !
Bruno

On 09.10.2023 05:58, Bruno Manzoni wrote:
Just receive this info from Jezzaaa (in the PoC "problem solving" repo).
(remark for anyone: If you can send mail to the mailing list: prefer it, if you cannot: no problem,? do what you can!)

Hi Bruno. Firstly, thanks for trying to find ways to progress Xymon, and Devmon too.

I think this is a good option for tracking problems and feature requests. I'm a bit old-school and while I've been using Github for a few years, I'm not familiar with all of its features and quirks. I agree that we need a single "collection point" for bugs/requests, and other forums can channel queries to here.

I'm a bit surprised you said "dev" info should not be here. Although perhaps I don't understand quite what you mean.

I would really like to see the Xymon source code imported into Github. I think this would be a great way to allow other developers to fork, test, and submit "pull requests" for merging. I think this would help the primary developers/maintainers to be able to manage patches.

Previously, patches were submitted in a number of ways. There's a "xymon-dev" mailing list, for instance, that some people used to submit patches. Others emailed the main mailing list with patches. I believe working with Git and Github can streamline this process.

My comments on some of these:

  * skinning - nice to have, and can "freshen" xymon's look
    (personally, I like the current look)
  * alternative dashboards - I suspect new dashboards can be added on
    without changing the existing code, by using the xymon client to
    query status from the xymond process via localhost:TCP/1984 (also
    see "Xymondash" - not sure how this works, but it's a new look
    that doesn't need the old look to go away)
  * repo is probably very important, but that's an uninformed opinion
    and JC/Henrik would need to be comfortable
  * make xymon up to date: this needs a fair bit of work client-side
    and server-side, but perhaps the server side can be extend to
    support per-OS plug-ins, and reduce the need to continually track
    OS changes
  * Moving away from C: I don't really see this as being all that
    useful. Other languages have useful features, but they all come
    and go, and C is the language that seems to have endless longevity
  * API: Xymon already has an API of sorts; but there might be some
    limited benefit in providing one or more other APIs such as JSON.
    However I suspect the popularity of JSON/REST and their ilk is
    going to wane over time, as other universal APIs come along. I
    think a CGI shim is probably the way to achieve this, and probably
    doesn't need any changes to the core code.

Other things high on my "requested features" list:

  * IPv6
  * SNMP that's robust, and has enough features to replace devmon