[Ns-developers] ns-3.1 roadmap

[Tom Henderson]

This is an update of this release planning based on the past two weeks 
of activity and discussion.

Tom Henderson wrote:
> 
> Major software issues
> =====================
> 
> 0) finish the Python bindings of the existing API
> 
> 1) how to make it easy for users to write their own Python bindings for C++ extensions that they implement
> 
Python has been subject to some list and off-list discussion (more below).

> 2) finalize ns log issues (existing mailing list thread)

this is checked in.

> 
> 3) finalize ns socket issues (existing thread)
>  - merge ns-3-simu?

This has been subject to some list discussion (more below).

> 
> 4) resolve trace path issues (existing thread)

this is checked in.
> 
> 5) finalize helper APIs
> 
> 6) PointToPoint and CSMA net device cleanup

Neither 5 or 6 has been updated yet.

> 
> 7) merge ns-3-doc?

this is checked in.
> 
> 8) move Doxygen to .cc files?

I think we can delete this suggestion.


Mathieu also posted a summary of what he thought were the outstanding 
issues, in this message from last week:
http://mailman.isi.edu/pipermail/ns-developers/2008-April/004044.html

To summarize, other than cleanup/documentation, it seems like there are 
two main topics that we need to progress:

Socket-related changes:
----------------------
The sockets API changes that have been summarized elsewhere (support 
changes to the API and implementations to allow the eventual inclusion 
of synchronous socket API, provide socket helpers or otherwise finalize 
the socket API, change the Packet Tag implementation to give it byte 
semantics).
- Mathieu recently posted an initial cut at the Tag revisions.
- I'm working on other socket-related changes

The target for resolving all of these socket API changes should be 
mid-May, I think.

Python-related changes:
----------------------
There have been a few issues raised on the list.  Gustavo has complained 
about tracking the moving target of the ns-3 API.  Mathieu suggested 
that Gustavo's reliance on GCC-XML is problematic for the typical ns-3 
user who wants to extend the system.

We had some additional off-list discussion about this last week.  In 
particular, a change from an automated binding generation to a more 
manual approach would be a drastic change to make at this stage of 
development.  Nevertheless, Gustavo agreed to consider whether a 
non-GCC-XML approach could be supported by his pybindgen library, and to 
report back what that would look like.  We will need to have more 
discussion of this topic on the list; the main point here is to note 
that there are some issues in flux with these bindings.

The consequence is that the previously scheduled inclusion of Python 
bindings must wait until these issues are resolved.  I'm hoping that we 
can decide on a way forward and also have a stable C++ core API by the 
middle of May; that will likely cause the Python bindings to slide out 
accordingly, keeping in mind that any drastic changes we make to what 
Gustavo has been developing will cause further schedule slip as well.


Please send further comments or suggestions to the list.  I've updated 
the roadmap page on the wiki to reflect the above:
http://www.nsnam.org/wiki/index.php/Roadmap

- Tom