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
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon