There's currently no distinction between the private and public parts of the protobuf API. A proper public API should be made by creating include files on the top-level (or includes subfolder) that any other module can use.
This module has several custom container classes to deal with missing functionality in core. These classes should either be generalized and put into a common module or replaced with newer classes that have been made. The following classes should be considered:
OpProtobufBitField and OpProtobufBitFieldRef should become a more generalized version. The OpProtobufBitFieldRef class is important for protobuf as it provides a non-templated access to the bitfield. The OpProtobufBitField class should get the same methods for manipulating the bits as OpProtobufBitFieldRef, this would make it possible (for non-protobuf code) to use the class without first fetching a reference object. The API should also be made closer to the bitfield class in STL or other common API.
OpValueVector was designed to support vectors of ints/floats/bools without having to use OpVector which instantiates a new instance for each entry. This class should be generalized and moved to a common module or replaced with a new class if available.
OpProtobufValueVector was a quick workaround for an issue with OpValueVector being used on the new OpString/OpData classes. With a proper value-vector class in core this class could easily be removed.
The name attribute of protobuf messages should be changed to uni_char.
Each generated message has a bitfield which is used to track whether a field is set or not. Currently this field also includes fields which cannot be unset (e.g. required field). By only including fields which requires this check the field can potentially be quite reduced for some messages. The bit offset is currently hardcoded from the field offset and must instead use a generated enum which has the correct offset.
The protobuf system was extended to support more than one container class for strings and byte buffers when the multiprocess code was introduced. This was need to support the new OpString/OpData classes which was used in the new code, while the existing protobuf code used in scope still used OpString/OpByteBuffer. As a result of this the code for serializing and de-serializing protobuf objects has become more complicated. The code now works on a type of iterators which returns ranges of string or byte data. There should be made some benchmarks to see if this code is significantly slower than the original code with just one type, if this is the case it might be a good idea to switch to a single class, for instance by updating scope to use the new string/data classes.
The XML support was initially added to support existing scope clients (e.g. urlplayer) which used the old XML structures. However there are currently no clients which uses XML anymore so there might not be any need for supporting this anymore. This needs to be discussed with the scope module maintainers.