[Xymon] Xymon version 5

[Adam Goryachev]

On 01/11/15 21:08, J.C. Cleaver wrote:
>
> I was actually planning on a roadmap update during the 4.3.22 announcement
> this week, but might as well post now. :)
>
> After 4.3.22 is released, I'll be opening up the 4.4 release. This is
> primarily focused on high performance and core features, including a
> back-port of the compression support from Xymon 5 (a/k/a "trunk"). It's a
> fairly large patch set that incorporates a lot of the work that had been
> done in the Terabithia RPMs. The potential for migration gotchas combined
> with the sheer size of the delta warrants a minor version bump, but it's
> still identifiably "Xymon 4".
>
> Xymon 5 is the trunk update Henrik has been working on for a while now.
> The biggest core features are 

Would it perhaps be useful to break down the above enhancements, and release them incrementally?
compression - version 4.4
sqlite as a data store - version 4.5
IPv6 - version 4.6
direct SSL communication support throughout - version 4.7
a new poller (xymonnet2) - version 4.8
and page generator - version 4.9
more streamlined client->RRD processing - version 5.0 (because now we have done everything that was needed for 5.0 :)

 

> Performance-wise, there's a lot of improvement in 4.4 which gives
> continued flexibility to the "roll your own" solutions for both
> DB-type/automated access and SSL wrapping of payloads, which are probably
> the two largest fundamental core features (outside of IPv6)... As
> mentioned, compression will be backported into 4.4 -- with support for lzo
> and lz4 on top of the original zlib -- but the rest hasn't made it in in a
> testable form.
>
>
> My plan is to get a 4.4 beta release out by the end of December.
>
>
> I'm also looking to complete full removal of display HTML and an easier
> way to deploy "themes" at the front end (which can, of course, link in to
> whatever custom display solutions are desired). Some of that might be 4.4,
> some might be 4.5, but IMO it's additional ways of visualizing / browsing
> data at the web layer that would most help the project's reach.
This could be good. One thing that might help improve performance of the
pages is to use some sort of persistent connection between javascript on
the client (browser) and the server. Then any status change can be
communicated in real time to the browser which can simply update the
icon and background colour as needed. This could also be used to read
real time status updates to pass to other systems/services.

Finally, separating the "theme" from the code will allow much greater
innovation with how the data is presented.

So, overall, I'm just wondering if we should create smaller targets such
that it is possible to add one feature at a time without as long a delay
between new feature release?

Regards,
Adam


-- 
Adam Goryachev
Website Managers
www.websitemanagers.com.au