Re: plans

[Jan-Henrik Haukeland]

Martin Pala <address@hidden> writes:

> Jan-Henrik Haukeland wrote:
>
>>... and the current language
>>does start to get messy.
>>
> I agree - it's not very funny.
>
> I think we shall maybe purge obsolete configuration statements in next
> major release to cleanup syntax and documentation. It will break
> backward compatibility (which is not good and popular) but it could
> ease the usage. For old style configs it is possible to supply upgrade
> script + upgrade documentation (which was prepared by Christian
> allready). I think new (and old) users will appreciate simple common
> syntax.
>
> What is your opinion?

I agree that language changes breaking backward compability must be
done in a major release to clearly set it appart from previous
releases. Christians upgrade document is also a good idea.

We have certainly done much already to make a major release (4.0), but
on the other hand the 3.2 release seems to work well, which means that
there is no need to rush a new 4.0 release. 

My original game plan was to add my stuff to monit, polish it a bit
and we should be ready to release in 1 or 2 weeks. But this was before
you brought up the language changes Martin. I really like your ideas
and to put them in a 4.0 release seems very reasonable to me.

Therefore; should we include the language changes you have suggested
and thereby postpone a 4.0 release *or* add the exec statement missing
now, pluss device polishing and release this as 4.0? If we choose the
later we can, as I said, have a 4.0 release ready soon, if we choose
to include the language changes we will probably have a 4.0 release
ready first in August/September. 

Cast your votes here:

1. Include language changes and release 4.0 when they are done (August) ?

2. Release 4.0 after the exec statement is included ++ and add
   language changes in a later release (1-2 weeks) ?

Number 1. is getting my 1+.


[FYI: There is a small consideration though: I have just joined a
small startup (imagine that! and we are even going to do Internet
technology! This company may be as dead as a canned herring (a fish)
in 4 or 5 months, but then again it may not and I can buy the Porsche
I always wanted. Yeah Baby! it's dot.com all over again (said with the
voice of Austin Powers ;-) So please understand I really must
prioritize this company and the work there. This certainly does not
mean that I will not work with monit, I will!  But it probably does
mean that I cannot put in as many hours working on monit as I would
like to. I thought I should let you know, so you know :]

Anyway, back to the topic or at least approaching the topic. Lately
and especially after I have implemented zervlet and there used many
new and improved C implementation techniques I *do* feel strongly to
refactor much of the monit code base because right now the monit code
base is messy (reflecting the language). I'm not so happy with the SSL
integration either. Christian has done much work on it and it works
fine but design wise I feel that it should be cleanly separated and
factored out. That is, the rest of the code should not have to know
about SSL at all and the messy details should be hidden in one or two
functions. port_send() is a good start, but using something like the
newly added socket.c is probably better.

What I would like to do is to splitt up monitor.h and have a single
interface for every source file and use a more object oriented
approach to the implementation. Take a look at the socket.c and
socket.h file I just added to see what I mean and please read this
documentation for the implementation technique I propose:
<URL:http://zervlet.com/doc/programming.html#structure> I hope you
agree with me on this technique. I do not mean that we should rewrite
the whole code base, but take one file at the time and only those that
makes for natural objects. To start, file.c alert.c log.c state.c and
sendmail.c are good candidates for objectification. Another thing we
could benefit from is this colletion of many nice ADT's (Hash tables,
lists, sets ++) which I have used much in the zervlet project.

<URL:http://www.cs.princeton.edu/software/cii/> See the download
link. The book is also very good, recommended! The C implementation
technique mentioned above is taken from this book.

Anyway, I think now is a good time to step back, reflect and think
about design and do two things:

1. fix the control file language.
2. Fix the code base (design).

Of course this may clash with the aforementioned FYI above, at least
for me, but I will put in my share. I'm interested to hear what you
guys are thinking about this.

> I personally preffer support for global and local methods
> definition. I think it is more flexible and universal syntax 

I agree, of course. For some reason I started to think in Cobol, I
mean with the section stuff and all :)

>> But what should be do with these statements?  checksum
>> /usr/local/apache/bin/http  timeout if 2 restarts within 3 cycles
>>  group server
>>  every 2 cycles
>>  depends sybase
>>  alert address@hidden on { checksum }
>>  host shop.sol.no port 443 type TCPSSL protocol http
>>
>>They are not if-tests per se. Should we leave them as is or modernize
>>them as well?
>>
> This is difficult one.
>
> Some of them produce event indirectly:
>
> 1.) group server
>
> This probably won't be big problem - group is used for
> start/stop/restart/status externally from the service's point of
> view => there are no bindings to other events

True

> 2.) depends sybase
> *
> TYPE {TRIGGER|PRIVATE} ... defines wheter the method will follow
> dependants. In the case that the method has 'trigger' flag, method
> with the same name is expected in dependant's configuration. If
> global method has 'trigger' flag true, then it is inheritted by all
> services and in the case that one chain link will run this method,
> all dependants will run it too and forward it to its children.
>
> 'TYPE PRIVATE' is default in the case where optional TYPE argument
> isn't specified at all - but the logic could be converse => TYPE
> TRIGGER could be default and you must specifiy 'TYPE PRIVATE' to make
> the exception (which is maybe more close to present behavior).

I think this may be to complicated and I'm not sure I understand all
of it :) I don't know if I even would touch the depend code again,
it's super complicated with lots of fancy recursion. Better to leave
it alone and use depends like we do today.

> [***]
> What about it? The example isn't the cleanest syntax - i tried to
> show the possible usage. In most cases the syntax could be very
> simple. There are plenty of areas which needs to be
> discussed/cleaned.

Absolutely, could you check into CVS a language design document and we
an use this document as a work in progress. You could for instance put
all the stuff you have suggested in this mail thread into the document
as a start. I was also thinking that if you care to "fine" write the
doc. you should send it to the monit-general mailing list as a RFD and
hopefully we/you will get more feedback from users. Sort of acid test
the proposal.

> The general flow is: event -> optional_methods -> optional_alerts

Yep, yep. maybe not so sequential more parallel like this, but I get
your drift and the theory sounds very good. An event driven model is
nice!

event --> optional_methods 
      |
      `-> optional_alerts


Regards
-- 
Jan-Henrik Haukeland