BMI goals and binary compatibility considerations

[hellkite500]

I'm trying to understand some nuance difference in the use and application of the interface component of BMI and would like to get feedback from the source as well as the community.

BMI exists as a conceptual interface described in broad terms by the SIDL definition. At the same time, it exists as a set of supported language definitions. This is what I would consider an application programming interface, or API. If this is correct, then these headers/modules represent the explicit machine/programming interface that comprises BMI in practice.

What I have seen in my experience with BMI, however, is that these two views, the conceptual interface and the API, don't always align well. For example, considering the concept of extensions as mentioned in other disscussion topics and issues, it seems that often times extensions are added to the BMI interface components (module, struct, class ect) directly to provide a "BMI Like" function that is not part of the existing specification but which provides convience and/or utility to a specific model.

This presents a compatibility and and interoperability issue, however, which seem counter to the goal of the conceptual BMI specification. My main question is which of the following goals of matter more to BMI?

• True binary compatibility and interoperability?
• Or, is the conceptual interface the primary goal and the supported BMI language definitions are more "guidelines" intended to be modified and used differently in different projects?

Perhaps it is both? In which case I think there is some lacking documentation and communication as to how both of these are supported!

I'm happy to discuss more details on this topic, but for now I just wanted to introduce the concepts and get some input to help steer the conversation.

[RolfHut]

For the purpose of our project (eWaterCycle) it is very important that we adhere to the first: true binary compatibility and interoperability. An extension can add functionality required for a certain model / application, but should never be incompatible with the core API defined for that language.