<html><head><style type="text/css"></style></head><body><div style="font-family:Courier New,courier,monaco,monospace,sans-serif;font-size:12pt">I like this thread! It raised another thought... (Please ignore me, if I am totally of track :-) If we think of it as two parts, a filebased DB backend and a webservice. Wouldn't it make sense to take a look at the DB schema used by Merlin & Ninja, or is it too heavy? Possibly the same schema could be used and potentially open for the use of Ninja (the officially "new" Nagios GUI) without involving Merlin. Don't get me wrong here. I really like Merlin, it rocks, but if you do not need all its funtionality a lightweight DB only alternative whould be nice. I realize that some information will be missing, but the potential of code re-use is there. For the backend my vote is on SQLite. It supports more client apps any way. I am not the man to judge pros & cons of JSON vs XML. But if we are talking web services, the client app does not need to be a web page. Is JSON suitable for other client apps as well? Just asking, I don't know. ______________________________________________ Sven-Göran Bergh Systemasis AB ______________________________________________<div> </div><div style="font-family: Courier New,courier,monaco,monospace,sans-serif; font-size: 12pt;"> <div style="font-family: courier,monaco,monospace,sans-serif; font-size: 12pt;"><hr size="1">Från: "yann.jouanin.list@intelunix.fr" <yann.jouanin.list@intelunix.fr> Till: Nagios Developers List <nagios-devel@lists.sourceforge.net> Skickat: tisdag 18 augusti 2009 10:27:57 Ämne: Re: [Nagios-devel] XML, JSON, Webservice or something new ? Using CDB or SQLite look a good thing for me. I didn't improved Nagios2JSON a lot cause it's a C CGI and it take long time to sanitize everything.. but if someone wants to help me in improving Nagios2JSON, then Welcome! As pointed out Thomas, I also wrote a patch to get status.dat directly writen in JSON but I think the major problem is what ever you want you'll parse the complete status.dat. Having a File DB instead of status.dat would be a real way to help in writing new XML or JSON interface in an easy way. I also did a python status.dat parser and rewrite Nagios2JSON with it to test how easy it becomes also with atomic query... Yann On Tue, 18 Aug 2009 04:11:09 -0400, Thomas Guyot-Sionnest <<a ymailto="mailto:dermoth@aei.ca" href="mailto:dermoth@aei.ca">dermoth@aei.ca</a>> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 17/08/09 10:08 PM, Max wrote: >> Hi Derrick, >> >> On Mon, Aug 17, 2009 at 8:32 PM, local.coder<<a ymailto="mailto:code@novageeks.org" href="mailto:code@novageeks.org">code@novageeks.org</a>> wrote: >>> I am back to writing some code for a new project involving Nagios. As >>> part of this I need light weight data access to status.cgi data. >>> Initially I was planning on modding ministatus.cgi which I know is not >>> part of the contrib anymore but it is a good starting place. At the same >>> time I looked into the status of something more standardized. I would >>> prefer to code to a standard that we can all get behind. The Nagios2Json >>> looks nice in that JSON is a basic format and gives me what I need, >>> however the current project is not Version 3+ compliant. I also found >>> the NXE addon for XML output but that has not been updated in some time. >> >> The only problem with the current nagios2json is that you cannot do >> discrete queries of hosts/services etc, so not quite ready for AJAX >> UIs. > > I like the JSON patch as it implement cleanly a different way of writing > status data to status files. However I had in mind doing something > similar but with CDB. CDB is a small and very efficient read-only > database format that has a C and PHP (among others) APIs. It store only > key-values and it is designed to be written once and acceded read-only; > just as status.dat works currently. OTOH, unlike status.dat it could be > queried instead of parsed in full so it would be a perfect fit for > systems that use an advanced web interface but want to avoid the burden > of ndodb. > >>> Before using one of these and making them work I would like to see a >>> standardized model for the XML or JSON data structure. I have seen >>> several items on the wishlist for a webservice interface and that would >>> also work really well but again a standard API would need to be created. >>> >>> What are others doing for small format host and service data and is >>> anyone deeply interested in coming up with some standardized XML or JSON >>> data templates ? >> >> I vote JSON :), works well with all sorts of web frameworks and for >> high volumes of data much less verbose than XML, we are needing this >> as well and I have been speaking with a teammate of mine on enhancing >> Nagios2JSON as we will be exposing a RESTful interface within our >> organization that lets people GET data out of Nagios with HTTP and >> will let them change our Nagios configuration as well to perform CRUD >> on our configs through web services. Nagios2JSON is Nagios 3 >> compatible (just have to use the VCS rev), maybe we could work >> together on it to enhance Yann's existing code? > > I sure would vote JSON over XML, but with JSON you still have to parse > the whole status file for every request. That just doesn't make any > sense for things like showing the status of a single host, especially on > large systems which have lots of services. This is even more true when > AJAX comes in mind; to be usable scripts have to respond quickly. If for > example you click to expand a host detail, it will be much faster if the > backend can just fetch and parse that host's data instead of parsing a > large file... > > - -- > Thomas > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - <a href="http://enigmail.mozdev.org" target="_blank">http://enigmail.mozdev.org</a> > > iD8DBQFKimId6dZ+Kt5BchYRAtDVAJ9qauN7iumyo6EI1pVcmdeRTXpb3gCeOG0P > w+ECcF+BgA1Y1MR2sGDYgQs= > =0ECl > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. <a href="http://p.sf.net/sfu/bobj-july" target="_blank">http://p.sf.net/sfu/bobj-july</a> > _______________________________________________ > Nagios-devel mailing list > <a ymailto="mailto:Nagios-devel@lists.sourceforge.net" href="mailto:Nagios-devel@lists.sourceforge.net">Nagios-devel@lists.sourceforge.net</a> > <a href="https://lists.sourceforge.net/lists/listinfo/nagios-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/nagios-devel</a> ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. <a href="http://p.sf.net/sfu/bobj-july" target="_blank">http://p.sf.net/sfu/bobj-july</a> _______________________________________________ Nagios-devel mailing list <a ymailto="mailto:Nagios-devel@lists.sourceforge.net" href="mailto:Nagios-devel@lists.sourceforge.net">Nagios-devel@lists.sourceforge.net</a> <a href="https://lists.sourceforge.net/lists/listinfo/nagios-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/nagios-devel</a> </div></div></div> <hr size=1> Låna pengar utan säkerhet. <a href=http://www.kelkoo.se/c-100390123-lan-utan-sakerhet.html?partnerId=96915014>Sök och jämför lån hos Kelkoo.</a></body></html>