[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Feature request: /etc/monit.d config directory and include support

From: Jan-Henrik Haukeland
Subject: Re: Feature request: /etc/monit.d config directory and include support
Date: Fri, 12 Dec 2003 04:50:17 +0100
User-agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Reasonable Discussion, linux)

Mark Ferlatte <address@hidden> writes:

> A very naive implementation could be as simple as having monit read
> the config into memory only looking for include statements; when it
> finds one, replace the line with the contents of the included file,
> else for each file in included dir, add them in lexigraphic order.
> Then use the existing parser on the string in memory.  :)

This is certainly an alternative way to handle 'include' parsing.
>> That brings us back to using XML for the config file and including
>> a small XML parser to read and write the config file.
> You know, this is not so bad, so long as you have a public DTD for
> the config file.  Having the ability to easily generate and validate
> the config file from a script is useful for me.

We will have to put in some work in creating a DTD and a good XML
format, so this will probably not happen in the next release, but I
suggest that we now tentatively plan to move the monit control file
syntax over to XML in the future.

The rationale:

 - Having monit write back a control file if configuration is changed
   at runtime via the monit web-interface is much easier to do if the
   control file is based on XML because a DOM parser can both read and
   write output.

 - With a DTD and an XML editor it should be easy for users to create
   and build a monit control file.

> What would be nice, of course, is if both syntaxes were supported
> for one or two releases so that people like me have time to
> transition.

That may be difficult, because if we switch to using a XML DOM parser
the internal data-structure representing the control file should
change to the DOM tree data structure. Making the code operate on two
alternative data structures will be difficult. Of course we could
parse today's controlfile syntax into a DOM tree structure but that is
much work for something that will be short lived. 

Jan-Henrik Haukeland

reply via email to

[Prev in Thread] Current Thread [Next in Thread]