Re: plans

[Rory Toma]

I vote for the language rewrite. I'm probably not much good with that,
but I can keep monit running on the BSD's and like of the world. Also,
that may hopefully give me enough time to figure out the "/proc" of
MacOS X.

On Tue, 2003-06-24 at 19:43, 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) ?
> 
> 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
-- 
Rory Toma               address@hidden
VP of Run Level 9       http://www.trs80.net
Digeo Digital           http://www.digeo.com

signature.asc
Description: This is a digitally signed message part