[Ns-developers] Thinking System-Wide?

[craigdo@ee.washington.edu]

Hi All,

I've looked at a couple of submitted patches in the last few days and I've noticed a developing pattern: a useful and interesting
new feature is submitted and implemented in a patch, but only implemented in some subset of models/helpers.

I don't think we should naively accept submissions succumb to this tendency.  We've worked hard to keep ns-3 architecturally
coherent and we should not begin to drift off into a situation where features are implemented incompletely or inconsistently.

I don't mean to point fingers, but, just as an example there recently was a submission to add friendly file names to pcap files.
This is a great thing, but if I remember correctly, it was only implemented for the Csma and PointToPoint helpers.  IMO, this should
be implemented for all helpers doing pcap or none.

Today I looked at a submission for limiting the number of bytes written to a pcap file from each packet.  This was implemented at a
low level in PcapWriter, but only plumbed into the YansWifiPhyHelper.  IMO, this should be implemented for all helpers doing pcap or
none.

If we were to happily push even just these two useful submissions as is, suddenly we would find that *none* of our helpers using
pcap traces would be consistent across the system.  This is a Bad Thing (TM).

I encourage everyone making this kind of change to think a little more architecturally.  Certainly this stuff should work across all
helpers implementing the underlying feature in the same way.  But also, for example, should the maximum capture size of the second
submission really be an Attribute?  Should there be an Attribute or GlobalValue to enable or disable friendly names in the first
submission?  I think we should absolutely do a thorough implementation across the entire spectrum of models using the conceptual
models we have developed, or we risk degenerating ns-3 from its current relatively consistent implementation into, well, a confusing
mess.

>From a maintenance and coding perspective, I think this also illustrates the dangers of naively using cut-and-paste to implement
helpers.  It wasn't a big deal when we just had a Csma and a PointToPoint device, but now there are five device helpers and an
internet stack helper that use pcap and all of these helpers must be located and changed in a consistent / identical way to do
anything interesting with respect to pcap traces.  This is a Bad Thing (TM).

I encourage people who find themselves making changes to identical code in multiple places (especially in five or six different
places as would be required here) to consider consolidating some of that code to make it easier to do this kind of change by
refactoring.  I encourage people to think about some of the architectural features of ns-3 that are designed to make using similar
features easier for the end user.

I know this is more painful than just implementing what you need, where you need it, when you need it; but I don't think anyone
wants to see ns-3 become a collection of seemingly random objects that each do different sets of things in different ways.
Sometimes a little more pain up front can prevent a lot more pain later.

IMO, if it can reasonably work the same way across all of the helpers using established architectural features, it should; and if
common code can be used to make this work better, it should be written -- unless there is a very good reason not to.  

I hope we can encourage submitters (and keep maintainers doing it) to think about how their bits might fit into the system as a
whole.

Regards,

-- Craig