Re: plans

[Martin Pala]

Jan-Henrik Haukeland wrote:

> 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) ?
I'm +1 for 1.

It is long time since we released 3.2, but as you said, it works good 
and it will be better to do bellow mentioned major updates in 4.0.

> 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.
I have the same meaning. Code is going to be pretty messy - monit 
changed a lot and to integrate new functions it will be better to 
consolidate/redesign the codebase (as you mentioned it can be much more 
cleaner by using more object programming techniques).

> 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).
Agree

> 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.
>  
I though about it in the nigth and figured out similar view.

>  
>
> > [***]
> > 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.
I will prepare it and try to reflect whole language design and its 
relationship to monit's behavior. I'm busy because of training today and 
tomorrow, i think it will be ready next week.

>  
>
> > 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
Agree. I though about it too - maybe it will be possible to start 
separate threads to take care for tasks like alert, methods managment, etc.

If some event occures, it then will be propagated to alert and methods 
in paralel. Thread/modular design can affect monit generally - we'll see :)

I prepared very approximate image of possible relationships i though 
about. Threads are shown as squares. It is event driven (the events 
relathionship description and flow isn't included - it will be topic of 
mentioned document).

Martin