2011/2/2 nap <napar...@gmail.com>
> Hi,
>
> I don't think it is a so good idea. The code is not so huge, and 90% of the
> code will be in the common part (if not more), so I don't think it's so
> useful to cut and complexify it.
>
> I do not see what the shinken.plugin can be in fact, maybe this one can be
> a good thing, but we won't redone all nagios plugins in the core, it's not
> the goal. Only some major one for transport like nrpe or check_nt for speed
> thing, but I do not think adding in the core the whole plugin thing is
> useful nor a good idea. Unless a huge link with Shinken core I prefer having
> another repository for this is someone want to write such plugins. Of course
> for modules they can be on the core repository, because without it they are
> useless.
>
>
> Jean
>
Jean :
if we would have a shinken package tree looking like this (not so so much
different than the current one):
*shinken*/ # we keep the base 'shinken' name for the shinken package
ofcourse.
*objects*/ # (or "conf_objects" ?) would contain all files defining all
classes for all "configuration objects" widely used by the different shinken
daemons, like:
# host, service, contact, timeperiod, module(.py), etc,
etc.. ; well anything that can be in a Config object (and transmitted by
the arbiter to the others shinken daemons) I think actually
*core*/ # would contains all "core" related code files: Satellite,
Daemon, Scheduler, ... modulemanager, ..., Item, ..., log, check, ... well
all that is really anything primary (and not contained in other subpackages
like objects/modules/..) needed/used by the different shinken daemons so
obviously.
## actually they could be all left in shinken/ but having a "core"
subpackage with them is not more difficult..
*daemons*/
## we can have either a subpackage or python module per daemon ;
doesn't matter actually:
arbiter
scheduler
reactionner
poller
broker
## this one is the most easy to do now : would just need to take the
*daemon.py files I just have created and rename them over there..
*modules*/ # exactly like now but is just missing the __init__.py to
make it a (sub)package.
( soon:
*plugins*/ # only for shinken *own* "plugins" (I'm speaking of native
python plugin here (when there will be).
)
I actually don't see more than that.
wdyt ??
clearly(more than now I mean) separating "core" & "conf objects" & "daemon"
code seems really helpfull (already from a dev point of view but also
eventually for distribution packagers), at least to me.. ofcourse a small
care must be taken when this would be done but if it can be relatively
easily done why not foresee it right now ? and I do think this can be very
relatively easily done..
greg.
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Shinken-devel mailing list
Shinken-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shinken-devel
