Development priorities

jNetPcap is growing rapidly in terms of usage and features. I have been prioritizing work. Up until recently the priorities were a bit too flexible and shifting from one thing to another. So I would like to make my priorities public and would apprechiate feedback and suggestions.

Right now, my biggest priority is anything to do with release 1.2 in order to get it out the door. Anything related to 1.2 currently will get highest attention. Next in line is the main development trunk tentitatively slated to be released as 1.3.

Version 1.2 priorities

Version 1.2 (deprecates already released series of 1.2.rc1-5 packages) and replaces it with a new feature set which removes support for Analyzers and high level functions. Version 1.2 will be composed of libpcap wrapper and packet decoder only with header support. This is neccessary in order to provide a subset of jNetPcap library as a stable piece of software worthy of production quality status. The analyzer and higher level features will continue to be developed for many months and are not suited for 1.2 if we are to make a stable release in any reasonable amount of timeframe.

Here are the highest priorites of recent and future work in order to get the version 1.2 to release status.

1. ^{(Status: Done)} Low level scanner updates: packet truncation, expanded header-record structures, flags, changes for support of heuristics
2. ^{(Priority: highest)} Header containers - standalone container objects which work with JFields and JSubHeaders. Deprecate current use of containers by JHeader extension.

Version 1.3 priorites

Version 1.3 is currently released periodically as a snapshot of the latest development trunk. It hasn't been fully decided which features will go into 1.3 or when it will go into normal release cycle.

The timeframe from 1.3 will be after version 1.2 becomes stable or nears stable status. This will be atleast a few months but before the end of this year (2009).

As for the features, exact feature set will be decided when we near an official release for 1.3. We can however say with some certainty that the following features will likely appear in 1.3:

• Analyzers and high level features
• Modularity with extra modules: GUI module, extra protocols module, IDE modules, etc..

So with that in mind here are a list of priorities for 1.3:

1. ^{(Priority: highest)} build script rebuild for support for modular software builds
2. ^{(Priority: high)} Flexible formats - too many data formats are builtin (hard coded). This is becoming a problem and a better more flexible mechanism needs to be designed for new data types and new data representations such as table data.
3. ^{(Priority high)} analyzer - API redesign - current design lacks native analyzer support, the API needs a major cleanup
4. ^{(Priority medium)} more core protocols - need to add remaining common protocols so they are part of jNetPcap core set.

Protocol module version 1.0

Not all protocols needs to be core protocols always distributed with jNetPcap. There are certainly a great deal of protocols that jNetPcap needs builtin for processing most commonly found protocols, but there are also whole families of protocols, which can be provided as an extension a user can choose to install if needed.

Other modules

Since jNetPcap is to become modular, each module will have its own priorities. For now these priorities have not been defined.

Here is a list of possible modules:

• Swing/SWT/GUI modules - provides a gui components to represent jNetPcap data for various gui frameworks
• IDE modules - make jNetPcap development easier in various IDEs. Remember as jNetPcap brings the power of full network analyzer and sniffer that can be utilized under IDE environment to provide comprehensive jNetPcap development (ie. think debuging header definitions while applying header definitions changes immediately to a capture file to see the effect that it had).
• Application modules - can release various OpenSource pre-build applications using jNetPcap. Although for application design jNetStream (a sister project) is better suited since it provides more higher level services and full capture file editing capabilities.