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

[Bruno Manzoni]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20231009/3cfdd96e/attachment.htm>