monit-dev
[Top][All Lists]
Advanced

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

Re: plans


From: Jan-Henrik Haukeland
Subject: Re: plans
Date: Wed, 25 Jun 2003 20:08:26 +0200
User-agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Civil Service, linux)

Martin Pala <address@hidden> writes:

> Jan-Henrik Haukeland wrote:
>>
>>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).

I have been thinking again :) When it comes to fixing the control file
language I'm for it, but when it comes to refactor the code base I was
wrong. Let me explain;

1) Refactoring and redesigning a code base like monit with 20K lines
   of C code is to much work for us. And from what I have seen in other
   open source projects (mostly in apache/jakarta) refactoring is most
   likely to succeed if it's done by *one* developer. None of us have
   time to do this, at least now. And to start something we cannot
   finnish is not good because it is a waist of time and work.

2) The old saying "if it work don't fix it" is still true.

What I propose instead is to do this INCREMENTALLY. That is, we do
*NOT* start with a grand new architecture plan and reimplement
everything. Instead we only refactor what we have to reimplement for
Martin's new language proposal to work. But when we reimplement new
stuff lets keep in mind the object oriented technique I proposed
earlier and when possible extract stuff from the monitor.h interface
and put it in a new header. This way we will refactor the code base
gradually but with real progress and with always a working monit
system in CVS.

In short, lets just start with reimplementing the language and do
refactoring only when it is necessary to implement new stuff.

This also means that we keep the current architecture and only change
it when we really have to do so. The current architecture is still
sort of an event driven architecture in that validate.c generate
"events" which it dispatch to the various alert_xxx functions :)

Thoughts?

-- 
Jan-Henrik Haukeland




reply via email to

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