Hi,
Am 13.03.2009 um 10:49 schrieb Juergen Schoenwaelder:
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?
The input languages currently supported by libsmi are based on a (more or less) common information model. Do you regard your new approach as being based on a different IM?
In this case, it would probably make sense to introduce identifier prefixes more specific than just "smi" for library identifiers that are specific to the IMs. I think, the library infrastructure functions should retain the prefix given by the library name *without* the "lib" prefix. (I cannot remember any library foo for which any of its exported identfiers are prefixed libfoo instead of foo.)
smiInit() -> smiInit() smiGetNode() -> smiStdGetNode() or smiClassicGetNode()
For a transitional phase, simple wrappers or macros could map the old identifiers (e.g., smiGetNode()) to the new ones (smiClassicGetNode()) to retain API compatibility.
Your new functions could then be named smi<NewIM><Function>().
A similar naming scheme could be applied to some of the data structures in smi.h.
Summary: 1. I don't like the "libsmi" prefix. 2. I would try to keep API compatibilty.
-frank