[Openvas-commits] r3333 - trunk/doc/website

[scm-commit@wald.intevation.org]

Author: jan
Date: 2009-05-12 13:11:17 +0200 (Tue, 12 May 2009)
New Revision: 3333

Modified:
   trunk/doc/website/openvas-devcon2.htm4
Log:
Assigning topics for agenda items. Reorganising the agenda. Added further
items.


Modified: trunk/doc/website/openvas-devcon2.htm4
===================================================================
--- trunk/doc/website/openvas-devcon2.htm4	2009-05-12 06:55:52 UTC (rev 3332)
+++ trunk/doc/website/openvas-devcon2.htm4	2009-05-12 11:11:17 UTC (rev 3333)
@@ -82,23 +82,37 @@
 
 <ul>
 <li> review the past 2 years of progress
-<li> plan future features
-     <ul>
-     <li> Walkthrough of all the pending CR's
-     </ul>
 <li> discuss core designs (towards OpenVAS 3.0)
      <ul>
-     <li> OIDs: final layout and assignment procedure
-     <li> how to get rid of the opevas-plugins module
-     <li> replace the current internationalization concepts
+     <li> Topic 1.1: tighter nmap integration (service detection, OS detection,
+          network discovery, network scans in contrast to host-based scans
+          and seamless integration of NSE scripts). Also relates to CR#26.
+     <li> Topic 1.2: How to establish scan tasks like "all Windows machines in this network".
+     <li> Topic 1.3: CR#23 and CR#24 and OIDs: Agree on standard family names and on subdirectory structures.
+          Final layout and assignment procedure
+     <li> Topic 2.1: New concept of scanner/manager separation (many consequences like
+          retiring OTP for client, having manager mandatory, ...). Big picture(?)
+     <li> Topic 2.2: list of internal stuff we want to get rid of (like arglists, hash
+          functions, use ini-file format). E.g. What can be replaced by glib functionality.
+     <li> Topic 2.3: New base data structures for cleaner objects, APIs etc. (e.g. "struct NVT {}")
+     <li> Topic 2.4: Reorganising openvas-libraries: to have a lightweight core and perhaps other
+          focused libraries to suffice needs of client, manager, etc.
+          Also includes reorganising OpenVAS-Client: Making dependency on
+          openvas-libraries could reduce code base a lot.
+     <li> Topic 3.1: Getting rid of NASL-based SSH stuff in favour of openssh(?)
+     <li> Topic 3.3: Replace the current internationalization concepts
           in nasl/server with a solution by standard technologies
-     <li> OVAL with OpenVAS
      </ul>
-<li> discuss how to extend NVT coverage
-<li> discuss whether and how to retire NVTs
+<li> Managing OVAL (and other script types) via OpenVAS
+<li> RDBMS data models for results, NVTs etc.
+<li> Walkthrough of all the pending CR's
+<li> Organising OpenVAS project (house keepers for web site, bug tracker,
+     NASL APIs, PR etc.). Possibly assigning people.
+<li> Topic 1.4: Harmonization/unification strategies for NASL code
+<li> Topic 3.2: discuss how to extend NVT coverage and how to retire NVTs
 <li> discuss professional services and how they relate to project
 <li> meet the members of the OpenVAS mailing lists in real
-     life and have a beer (or other beverages)
+     life and have beers (or other beverages)
 </ul>
 
 <h3>Place</h3>