NSClient++ Help (#1) - developer guide (#1022) - Message List
Hi all, I'd like to extend the functionalities of nsclient++ so my question is: is there any developer's guide/how-to which explains how to add new modules?
-
Message #2696
Not really no... If there is an interest I could start it. It also depends on whiich route your aming for.
You can extend nsclient++ via:
- C/C++/* as complied DLLs/unix library files
- "External Scripts" (in any language exeutable on your platform)
- Lua
- Python
- .dot-net (C#, basic et al.)
Regardless of choise (except for external scripts) the API is similar.
The best place to start is the various existing code I guess...
but let me know what your plans are and I will gladly help you get started and writ up some documentation on it...
Michael Medin
mickem07/17/12 15:42:41 (10 months ago)-
Message #2698
Thank you for the answer. The idea is to add new checker commands by adding new DLLs. As example let's say I'd like to add a new command identified by #99, named checkFoo(param1), and its implementation is in a new module named CheckFoo?.cpp (which will be build in CheckFoo?.dll) Are there any "quick & dirty" steps to add this customization?
cal07/19/12 12:02:32 (10 months ago)-
Message #2705
Right,
Well, let me start out by adding a sample module which will show how to do it. When using from C++ there are (sort of) two APIs to use. There is a RAW API which is what the core/module use to communicate and there is the wrapped API which is what I use when I write my modules.
In essence the wrapped API acts as a "glue" and is there to make it easy to write plugins and not have to deal with all the nitty gritty details.
Using the "glue" requires you to have the NSCP sources as well (the raw API does not apart from protocol buffers I guess).
A good place to start if you want to use the "wrapped API" is for instance https://github.com/mickem/nscp/tree/master/modules/CauseCrashes which exposes a single command which can be used from remote hosts.
The "drawback" to using the wrapped API is that it is evolving as things are changing so there are often changes here and there (though they often not noticable). But for shore it will change more then the core API.
I will create a sample plugin which uses the RAW API as well but that is a bit more involved.
Also note that the API will change throughout 0.4.x versions as I am slowly shifting away from the native API towards a pure google protcol buffer API. But unless you want to do a lot of advanced stuff this will also not be very noticable...
But to recap. I'll try to get a sample plugin using both RAW and wqrapped API out in the next week or so...
Michael Medin
mickem07/23/12 13:03:33 (10 months ago)-
Message #2706
Thank you very much, I'll look forward to seeing your sample plugin!
cal07/23/12 21:02:25 (10 months ago)-
Message #2708
It would be also welcome a guide for the initial setup of a reference development environment. (After downloading all the sources from git, I feel a little bit lost... even by opening the .vcproj it seems it's not straightforward)
cal07/25/12 21:06:32 (10 months ago)-
Message #2709
0.3.9 version?
Anyways with 0.4.0 I have switched to cmake which I hope will make things simpler. Currently the idea is to make the cmake environment "chatty" in other words have it tell you what is required.
There is some random bits and pieces here build/04x but in short grab the source, start cmake and point it to the folders you want to use and click generate...
Then open the generated solution and build it...
Michael Medin
mickem07/25/12 21:48:08 (10 months ago)-
Message #2710
Hi, yes I'm talking about 0.4. My question was about how to setup a reference development environment in general terms. So the first step would be to define the prerequisites for a build environment:
- what operating system? (if Windows, is cygwin required?)
- what C/C++ compiler? (GNU? Sun? Visual Studio [6|2005|2010]?)
- which additional tools are required? (make? cmake? ...)
- which additional includes/libraries are required? (eg. Boost)
and so on.
Later, the second step would be to define how to build the whole project and produce the binaries:
- run the command XYZ in a cygwin bash [...]
- open the solution XYZ.sln in Visual Studio and click on build [...]
- whatever else...
The aim is to have a step-by-step guide which allows a programmer to fetch the sources from git and build them to obtain the same binaries also available for download. (I'm willing to contribute to this doc if needed, but I need the above hints)
cal07/26/12 15:14:36 (10 months ago)
-
-
-
-
-
