Strategies for dealing With incompatibility

As long as we are developing the CellML tools, we are going to have to break compatibility from time to time. This document is intended to list potential ways in which compatibility could be broken, and look at ways by which we could minimise the impact of this on the end user.

Potential sources of incompatibility

(and what they break)

• Changes to interfaces, especially XPCOM::IObject.

   

  This could prevent IIOP interoperability between almost any component, because they will try to call operations which don't exist, causing CORBA exceptions.
  This could cause Mozilla to crash if a bridge doesn't implement the same class as an XPT used to try to call it
  This could cause problems for Javascript code, which tries to access interface methods which no longer exist.
  We could solve the IIOP interoperability problem between components by not changing interfaces once they have been released, and instead defining new separate interfaces. This will be made easier if we try to develop minimal interfaces which completely perform some task, and just add new interfaces when new operations are needed. We should never change the signature of an existing operation, adding new operations is not as bad.
  We could solve the Mozilla crash issues by ensuring that bridges and XPTs for a given interface are only ever shipped in a single package, which other packages depend upon. This means that all code outside of these packages must be written in Javascript.
  We could minimise Javascript incompatibility issues by keeping deprecated operations and attributes for a little while before they are completely removed. Once they are removed, the user will need to upgrade.

• Changes to the CellML Context.

   

  Since everything depends on the CellML Context, we cannot remove any operations or change the signature of an operation (except during development).

• Changes to the Physiome C++ Mapping rules.

   

  The most likely change to the rules is to clarify it for something which we haven't already used. We can do this without problems.
  We cannot change the mapping of anything currently in use, if both binary versions are going to exist in the same process. However, this probably isn't a big issue, because we will generally upgrade an entire process at the same time (except the Mozilla process, but PCM isn't use Mozilla-side)