Changes between Version 5 and Version 6 of RoadMap

Timestamp:

05/07/10 09:32:59 (14 years ago)

Author:

Samuli Seppänen

Comment:

--

RoadMap

@@ -14 +14 @@
  * 6th May 2010
   * The roadmap meeting. James' views about OpenVPN 3.0 are available [wiki:RoadMap@1 here]
+
+ = Current issues and potential fixes =
 
  == Monolithic architecture ==
@@ -32 +34 @@
 The current non-asynchrous-clean status of the event system makes maintenance of certain OpenVPN components quite tenuous, such as mtcp.c. While the current event model is partially asynchronous, it is not sufficiently clean to allow certain features to be implemented such as concurrent multithreading or the ability to listen on multiple interfaces simultaneously. The limitations of current event system are also closely tied to OpenVPN's lack of multithreading. To get these features the current i/o event system needs to be revamped into a true asynchronous model. It might be worthwhile to look into using libevent as the underlying i/o event system for OpenVPN (libevent is used by memcached).
 
- = OpenVPN 3.0 =
+ = OpenVPN 3.0: Development issues =
 
  == Organic vs. planned development ==
@@ -42 +44 @@
 Starting from scratch has the benefit that we can focus on fixing the current architectural problems. Also, we would not really need to start from scratch, as many parts of the old codebase can be utilized in the new codebase with minor modifications. However, as the codebase as whole would be new, it would almost certainly have unknown problems.
 
-There is also the problem that the new codebase will be competing for users and developers against the old codebase. Non-developers are unlikely to use the new codebase until it provides something the old codebase does not. This means the new codebase will be relatively untested for a long time even after it's somewhat functional. Attracting developers to work on the new codebase may also be difficult unless somebody (e.g. at the company) bootstraps and leads the development effort.
+There is also the problem that the new codebase will be competing for users and developers against the old codebase. Non-developers are unlikely to use the new codebase until it provides something the old codebase does not. Attracting developers to work on the new codebase may also be difficult unless somebody (e.g. at the company) bootstraps and leads the development effort. This means the new codebase will be relatively untested for a long time even after it's somewhat functional. To minimize this time period we'd need solid data on how people use OpenVPN (e.g. what features) and focus on developing those. Asking the users directly (e.g. on mailing lists) would help, but the dataset would be relatively small. An automated opt-in system similar to [http://popcon.debian.org/ Debian's popularity contest] would give a larger dataset, but would have to be coupled with a new software release to get widest possible audience.
 
-Incremental approach solves the problem with competing codebases. However, as software architecture is difficult to change afterwards, incremental approach works only on a limited subset of the code. Some of the problematic code may be too integrated to be fixable without significant changes.   
+Incremental approach solves the problem with competing codebases. However, as software architecture is difficult to change afterwards, incremental approach works only on a limited subset of the code. Some of the problematic code may be too tightly integrated to be fixable without invasive changes. However, using the incremental approach whenever possible makes most sense.
 
- == Generic network stack vs. focus on VPN functionality =
+ == Generic network stack vs. focus on VPN functionality ==
 
+In the roadmap meeting (6th May 2010) James presented [wiki:RoadMap@1 his views of OpenVPN 3.0]. In a nutshell, OpenVPN 3.0 would become a generic user-space network stack. This would solve many of the architectural problems with the current codebase. This approach would also ''potentially'' allow a much wider user- and developer base as people could build non-VPN functionality on top of the core.
+
+The big question is whether going 100% generic is beneficial or not. If there's no interest in a generic userspace network stack then focusing on VPN functionality and just modularizing and cleaning up the code would be the best option.