[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [ns] improving the ns development



On Tue, 7 Aug 2001, Neundorf Alexander wrote:

> 	Well, most people (at least me) start with small patches,
> which are not really worth posting if there is a more or less high
> barrier :-(

Yes, they are. Post these small patches to the mailing list, which
gives you the right to bitch about how they weren't committed the next
time the problem is encountered. At least the information is there for
others to use.


> 	One example: the gsm/gprs extension from Richa Jain would be
> a very good candidate for ns, or the BlueHoc from IBM,

those are large extensions adding new functionality rather than useful
fixes/patches.

> but since
> there are these barriers, they don't get into ns that fast. If
> they were inside ns, more people would test them, find bugs,
> extend them, fix them :-).
> 	Really.

They'd also be expected to work because they're in ns. Updating parts
of ns to match changes to ns is a large task, and something often gets
missed. Being in ns doesn't guarantee the functionality will continue
to work - look at the history of snoop.

ns is already too large to be easily maintained.

> > Couple that with a bsdish model (knowledgeable few doing little after
> > careful thought) rather than linux development model (clueless many
> > doing lots - ns isn't a kernel, and spotting simulation errors needs
> > greater clue than whining that the latest kernel wouldn't boot) and
> > lack of available time to test and commit patches posted to the
> > list... goodbye, third-party synergy. 
>
> 	I really doubt this.

The validation tests could be a lot more complete. Interpreting what
the tests tell you when something breaks can be quite tricky.


> I don't think that there are qualitative differences in software
> developing depending on which kind of software is developed.

There's a difference between 'testing to work' and 'testing for
meaningful results known not to be misleading'.


> And I also think most people who *use* ns also more or less know
> the code of ns and therefor are not really "clueless".

Well, I use ns, and I'm clueless. Don't ask me about adhoc routing
or wireless code, or how classifiers work.


> With more "core" ns developers on the
> mailing list they would become "knowledgeable" even faster.

Nice idea. In theory. I doubt most core ns developers read this
list...

if more discussion of ns developments was public, it would increase
the rate of learning for third parties, yes. this list is a vital
resource.


> 	But as it is now, everybody hacks around, but since nobody
> sees the changes, it remains "desperate hacking" :-(

I'm beginning to think that this is normal for any mature codebase.


> 	I don't think ns needs any more features. What it needs is for the
> > existing features to work together in a more coherent fashion.
> 
> 	Well, ns definitely misses support for mobile cellular
> systems (gsm, gprs, umts). 

No, that's just buzzword featurism; you can approximate these at a
suitable (if very crude) level of abstraction with what's already in
ns, and a lot of GSM-like work has already been done with ns.

What's missing from ns is universal tracing, is having the multicast
code coexist with the wireless code, is avoiding C++/OTcl duplication
of functionality, favouring C++ wherever possible...

L.

<[email protected]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>