laforge wrote in #note-1:
I really don't think we want to do future changes to the PCU interface at all.
I'd hope that in 2023 we finally reach a point where we can consider a lot of the
code base going more into maintenance mode rather than continuing large feature
developments which introduce breaking changes.
Interestingly enough, those last few PCUIF versions were introduced not in the scope of adding new features, but actually in the context of fixing long-standing problems we had.
You also always have to keep in mind the use on CPU constrained systems like sysmoBTS,
where additional parsing overhead might matter.
It should be clarified that the actual idea was to use TLV based encoding not for all PCUIF messages, but only for the INFO.ind.
This message is not as "hot" as DATA.{ind,req}, for instance, so I would not expect any significant performance impact.
I'm therefore not in favor of spending a lot of time converting all PCUIF users
to yet another new protocol/encoding where it's unclear if we ever will need it,
and whether it will generate performance problems on old sysmobts hardware.
I agree that doing another PCUIF version bump just for improving the coding/flexibility of INFO.ind is not reasonable.
But if we ever have to extend the PCUIF again, I believe we should take a chance and move to TLV based coding for INFO.ind.
This way we could avoid bumping PCUIF version again and again when adding new fields.
