On Donnerstag, 20. November 2008, Stjepan Gros wrote:
> > My idea was that we should start with a
> > struct NVT_Desc {} in OpenVAS-Client and step-by-step
> > change to this strucure (which members are some Glib Datacontainers)
> > all over the client. Probably some lessons need to be learned.
> > Once finished this, the gained experience should be good
> > enough to approach the server.
>
> I couldn't figure out from this short description what you exactly intend to
> do.
>
> I was looking a bit into arglists.c and it seems basically to be a
> hash table that allows different objects to be stored and quickly
> retrieved. The closest data structure in GLib seems to be GHashTable.
> The problem is that GHashTable stores pointers so another layer above
> it is necessary in order to replace arglists.c. In conclusion, it
> would be relatively easy to modify arglists.c to use glib's functions
> while the rest of the code stays unchanged.
the main goal of a change towards glib should be to improve
readability of code and to reduce code.
So, while your observation is quite interesting, I am not sure
yet how much source code could be eliminated this way.
Readability probably would not improve.
> But, there is still a problem. The layer implemented on top of glib
> would be necessary in openvas-client and openvas-libraries, meaning
> that the code duplication isn't solved. To solve this problem, two
> approaches could be used:
Indeed this problem would remain unsolved.
> 1. Using your solution which I assume integrates parts of the code
> into openvas-client itself and totally removes nessus subdirectory?
> 2. Keeping in code in SVN in on only one place, while before doing
> releases duplicate code so that openvas-client is stand alone. In
> other words, users who download some (pre)release do just standard
> configure, make, make install process, while users who check out from
> svn have to install openvas-libraries before client (I assume they are
> advanced users per definition).
Eventually, nessus subdir should be eliminated. Frankly, I do not expect
this to happen soon.
My appraoch aims at removing arglist, harglist and some other modules
from openvas-client/libnessus/ and replace them by something like
openvas-client/src/core/ovas-data.c
Eventually this module will move into openvas-libraries (at the time,
openvas-client is made dependent on openvas-libraries). And the next step
after this would be to replace arglist & friends from openvas-libraries
by the new methods.
Sorry, that this is still a bit fuzzy. The ideas are not fully developed yet.
Best
Jan
--
Dr. Jan-Oliver Wagner Intevation GmbH, Osnabrück
Amtsgericht Osnabrück, HR B 18998 http://www.intevation.de/
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
_______________________________________________
Openvas-devel mailing list
Openvas-devel@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
