[Xymon] Is this thing on? Update #2 Feedback

[Bruno Manzoni]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20231009/01bf7293/attachment.htm>