Hi,
thinking about how thew new GUI for Nessus Client could
be incorporated into the main development there are
a couple of principle ways to do so. All with
their advantages and disadvantages.
1. Step-by-Step integration into current nessus:
Add new new GUI frame to current nessus CVS
and make sure, the version as it is now
exists as a GTK frame within the new GUI
so that everything can per performed with
the GUI all the time.
Then step-by-step add the funcationality to
the new GUI parts and after replace them in the old.
Eg. one of the first things would be to replace
the connect dialog and the scan options.
Advantage: All developers see the current status,
can comment or veto immediately. Also, there will
always be a functional version all the time.
Disadvantage: Its not really possible to improve the
whole implementation structure, ie. we may have to live
with the way some things are already implemented.
2. Separate development of 'nessus2':
A new CVS directory (e.g. nessus-client or nessus2)
where a fully separate development is started and some
parts of the current nessus client are copied from.
Advantage: New, straight implementation design.
Disadvantage: Probably no one tests it during development.
We might end up with two nessus clients to maintain instead
of creating a real successor.
3. Develop in a branch:
This is pretty much a mixture of (1) and (2).
the nessus module is branched and deveopment takes
place like in (1).
Advantage/Disadvantage:
Well, I don't see any advantage of this option.
A Merge back to HEAD would be pretty much the same
as exchanging all the code since the changes will be
comprehensive.
And this option would win more testers than (2).
What do you think?
My personal favorite is (1) so far as it really would mean
that we develop something that is permanently reviewed
by developers and users. A fact I rate very high.
Are there possibly other options I missed?
Best
Jan
--
Jan-Oliver Wagner http://intevation.de/~jan/
Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/
thinking about how thew new GUI for Nessus Client could
be incorporated into the main development there are
a couple of principle ways to do so. All with
their advantages and disadvantages.
1. Step-by-Step integration into current nessus:
Add new new GUI frame to current nessus CVS
and make sure, the version as it is now
exists as a GTK frame within the new GUI
so that everything can per performed with
the GUI all the time.
Then step-by-step add the funcationality to
the new GUI parts and after replace them in the old.
Eg. one of the first things would be to replace
the connect dialog and the scan options.
Advantage: All developers see the current status,
can comment or veto immediately. Also, there will
always be a functional version all the time.
Disadvantage: Its not really possible to improve the
whole implementation structure, ie. we may have to live
with the way some things are already implemented.
2. Separate development of 'nessus2':
A new CVS directory (e.g. nessus-client or nessus2)
where a fully separate development is started and some
parts of the current nessus client are copied from.
Advantage: New, straight implementation design.
Disadvantage: Probably no one tests it during development.
We might end up with two nessus clients to maintain instead
of creating a real successor.
3. Develop in a branch:
This is pretty much a mixture of (1) and (2).
the nessus module is branched and deveopment takes
place like in (1).
Advantage/Disadvantage:
Well, I don't see any advantage of this option.
A Merge back to HEAD would be pretty much the same
as exchanging all the code since the changes will be
comprehensive.
And this option would win more testers than (2).
What do you think?
My personal favorite is (1) so far as it really would mean
that we develop something that is permanently reviewed
by developers and users. A fact I rate very high.
Are there possibly other options I missed?
Best
Jan
--
Jan-Oliver Wagner http://intevation.de/~jan/
Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/