MaintainersApril2024
Main Page - Current Development - Developer FAQ - Tools - Related Projects - Project Ideas - Summer Projects
Installation - Troubleshooting - User FAQ - HOWTOs - Samples - Models - Education - Contributed Code - Papers
This meeting is open to anyone interested.
Date/Time/Venue
occurred at Thurs. Apr 4, 2024 09:00 AM Pacific Time (US and Canada) (16:00 UTC)
Agenda
Discuss adoption of the following proposals:
1) Addition of wifi (and possibly other) C++ namespaces: Merge Request !1906
2) Addition of strongly-typed units: Merge Request !1887
Minutes
Attendees: Tommaso Pecorella, Alberto Gallegos, Tom Henderson, Gabriel Ferreira, Eduardo Almeida, Peter Barnes, Sebastien Demone, Stefano Avallane, Biljana Bojovic, Evan Black
1) Addition of wifi and other namespaces
Consensus was:
- to move forward with !1906 now, pretty much as is. This does not put helper directory into the 'wifi' namespace
- Stefano will put together a follow-on MR or commit to add helper classes. The discussion here was whether to include or not, and if we include, how we will use 'using' type aliasing to allow some backward compatibility. No decision taken yet-- will evaluate the follow-on MR.
- ns-3 namespaces names will be in lowercase, such as 'lrwpan', 'wifi'
- no need at this time to put other modules into separate namespaces. we will experiment with Wi-Fi. Tom suggested that perhaps 'technology-specific' modules could go into their own namespace, while technology-independent such as core, mobility, propagation, etc. could stay in namespace ns3
- maintainers for other technology specific ('lrwpan', 'sixlowpan') can also move forward with this if they want.
2) strongly-typed quantities and units
No consensus reached at this time; maintainers will look more closely at alternatives.
Alternatives:
- Jiwoong's proposal in !1887
- Extend what we have (DataRate, Time, Length) and just add a few more (Power, Frequency, Angle...)
- Adopt an external library, either header inclusion or external library linkage. (e.g., Boost, mp-units, Au, nholthaus, ...)
Discussion points:
- Sebastien argued for adoption particularly for power and frequency quantities in wifi
- Tom argued more for extending what we have, based on reducing friction to users (avoid API changes, compatibility with attribute system, installation, Python bindings, compilation error output)
- Peter argued more for adoption of external library, to avoid maintaining ourselves, and to leverage the power of type-safe conversions (e.g. Energy/Time = Power)
- Eduardo: felt that the benefit of custom types is operator support, and that we had basic choice between doubling down on what we have (custom types supporting units) or keep with the basic types and use naming conventions (suffixes) to denote units
- Tommaso remarked that the most complicated part is conversion between types, suggested to avoid. Peter responded that conversion is the most powerful aspect of adopting this, and that we can't avoid dealing with conversion.
- Eduardo asked about whether we put these types into core or separate module such as Jiwoong did (units). Tom suggested into 'core'.. Peter suggested maybe a submodule in 'core'.
- Gabriel again suggested to look at mp-units
