<div dir="ltr">How big of a thing is "direct SSL communication support throughout" going to be?  I mean, what will that cover?  I'd really like to see encrypted client-to-server connections, because I'm required to encrypt all network traffic.  At present I'm handlng it by using curl to send to xymoncgimsg.cgi.  It works well enough for a small number of clients, but is becoming unreliable as more are added.<div><br></div><div>Ralph Mitchell</div><div><br></div><div>  <br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 1, 2015 at 10:09 AM, J.C. Cleaver <span dir="ltr"><<a href="mailto:cleaver@terabithia.org" target="_blank">cleaver@terabithia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Sun, November 1, 2015 2:18 am, Adam Goryachev wrote:<br>
> On 01/11/15 21:08, J.C. Cleaver wrote:<br>
>><br>
>> I was actually planning on a roadmap update during the 4.3.22<br>
>> announcement<br>
>> this week, but might as well post now. :)<br>
>><br>
>> After 4.3.22 is released, I'll be opening up the 4.4 release. This is<br>
>> primarily focused on high performance and core features, including a<br>
>> back-port of the compression support from Xymon 5 (a/k/a "trunk"). It's<br>
>> a<br>
>> fairly large patch set that incorporates a lot of the work that had been<br>
>> done in the Terabithia RPMs. The potential for migration gotchas<br>
>> combined<br>
>> with the sheer size of the delta warrants a minor version bump, but it's<br>
>> still identifiably "Xymon 4".<br>
>><br>
>> Xymon 5 is the trunk update Henrik has been working on for a while now.<br>
>> The biggest core features are<br>
><br>
> Would it perhaps be useful to break down the above enhancements, and<br>
> release them incrementally?<br>
> compression - version 4.4<br>
> sqlite as a data store - version 4.5<br>
> IPv6 - version 4.6<br>
> direct SSL communication support throughout - version 4.7<br>
> a new poller (xymonnet2) - version 4.8<br>
> and page generator - version 4.9<br>
> more streamlined client->RRD processing - version 5.0 (because now we have<br>
> done everything that was needed for 5.0 :)<br>
<br>
<br>
</div></div>That type of thing might work, though that does mean committing to the<br>
order somewhat ;)<br>
<br>
sqlite in xymond in particular (rather than the channel workers) is a<br>
pretty large change that could have some performance impact over the tree<br>
structure in use now.<br>
<span class=""><br>
<br>
>> I'm also looking to complete full removal of display HTML and an easier<br>
>> way to deploy "themes" at the front end (which can, of course, link in<br>
>> to<br>
>> whatever custom display solutions are desired). Some of that might be<br>
>> 4.4,<br>
>> some might be 4.5, but IMO it's additional ways of visualizing /<br>
>> browsing<br>
>> data at the web layer that would most help the project's reach.<br>
<br>
> This could be good. One thing that might help improve performance of the<br>
> pages is to use some sort of persistent connection between javascript on<br>
> the client (browser) and the server. Then any status change can be<br>
> communicated in real time to the browser which can simply update the<br>
> icon and background colour as needed. This could also be used to read<br>
> real time status updates to pass to other systems/services.<br>
<br>
<br>
</span>Possibly. The problem there is that keeping an active channel open<br>
directly into xymond (for what are essentially push notifications) has the<br>
potential for impact to the core, which we generally want to avoid. It'd<br>
be safer to isolate that by having a --channel=stachg worker writing to a<br>
location that can be queried by other processes, optionally notifying, so<br>
that message processing isn't affected.*<br>
<br>
Generally speaking, though, yes. An AJAX-y dashboard can dynamically<br>
update the page without reloading the view, and that's exactly the type of<br>
thing that can be provided.<br>
<br>
<br>
(Intermittently querying for changes can actually be done now with an<br>
appropriate "appfeed" filter command, like<br>
<a href="http://www.example.com/xymon-cgi/appfeed.sh?filter=color=red,yellow,green+lastchange" rel="noreferrer" target="_blank">http://www.example.com/xymon-cgi/appfeed.sh?filter=color=red,yellow,green+lastchange</a>>1445783474<br>
, which will give you XML for anything that's changed in the last week or<br>
so.<br>
<br>
*This does also raise the possibility of providing HA/mirroring directly<br>
within xymond. A read-only xymond replicated mirror can be used for report<br>
generation and whatnot.)<br>
<span class=""><br>
<br>
><br>
> Finally, separating the "theme" from the code will allow much greater<br>
> innovation with how the data is presented.<br>
<br>
</span>This is definitely the goal. The display we have now has certainly stood<br>
the test of time, but can be off-putting to those expecting e.g., a<br>
Nagios-type experience.<br>
<br>
The existing CGIs now can be replaced with whatever one likes, header<br>
customization can be used to wrap xymongen-generated page to match, and<br>
channel workers can be written to process data into any sort of message<br>
bus or DB (all RRD data at SNC gets written to a rotating tmpfs log, which<br>
is ingested by a Big Data system for further analysis and a distinct<br>
dashboard)... The problem is that doing all that requires a fair amount of<br>
xymon experience to architect something customized to what your site<br>
requires; lowering the barrier to entry for that will help.<br>
<span class=""><br>
<br>
> So, overall, I'm just wondering if we should create smaller targets such<br>
> that it is possible to add one feature at a time without as long a delay<br>
> between new feature release?<br>
<br>
</span>It's definitely something I'll keep in mind.<br>
<br>
Part of the problem this year was that I really only intended to pause<br>
development for about a month after 4.3.21 was released -- there'd been a<br>
lot of updates leading up to that and I wanted a chance to let it settle a<br>
bit. Unfortunately, one month became one full quarter :/ The pace between<br>
new feature releases is definitely going to pick back up going forward,<br>
one way or the other.<br>
<br>
<br>
Regards,<br>
-jc<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
Xymon mailing list<br>
<a href="mailto:Xymon@xymon.com">Xymon@xymon.com</a><br>
<a href="http://lists.xymon.com/mailman/listinfo/xymon" rel="noreferrer" target="_blank">http://lists.xymon.com/mailman/listinfo/xymon</a><br>
</div></div></blockquote></div><br></div>