Hi,
we are implementing support for an additional data modeling language and it seems that the feature set of the language we are currently working on is pretty different from the classic SMI/SPPI/SMIng languages libsmi supports.
So the question was raised to what extend it makes sense to try to retrofit things into existing data structures and APIs or whether we should have a separate set of data structures and API functions. We believe, the later approach makes more sense and API usage simpler. It will also make it clearer at the API level that you have to call explicit conversion functions if you want to convert a module between different languages. So in a nutshell, functions with the smi prefix or data types with the Smi prefix would be SMI/SPPI/SMIng specific while functions with some other prefix would be specific to other data modeling languages.
Now, there are a bunch of API functions that are really not specific to the SMI/SPPI/SMIng languages but to the library as a whole. I am talking about the functions documented in the smi_config(3) manual page essentially. If the follow the path that the API function prefixes indicate the "framework" they should be used with, then these library infrastructure functions should actually have a "libsmi" prefix, so you would write libsmiInit() or libsmiSetSeverity() or libsmiSetErrorHandler(). Providing ABI backward compatibility should be easy; I think this is more a question how we envision the evolution of this library.
Comments?
/js