This can cause backwards compatibility problems. If they reuse the CARP namespace (as has happened), conflicts can arise once CARP core introduces types with the same ID in that namespace.
Conceptually, dk.cachet.carp should be reserved for CARP core only.
Maybe I should disallow custom types in carp namespaces, but provide an option to disable that constraint for backwards compatibility.
The question is where, though. It could fail on service endpoints whenever unknown types are received in the dk.cachet.carp namespace. But, that'd be a useless check the vast majority of time, just wasting CPU cycles (albeit neglible). Maybe it can be a warning in the list of possible deployment issues as part of evaluating study protocols?
Currently, there are no constraints on type IDs for frameworks extending CARP with their own domain objects.
This can cause backwards compatibility problems. If they reuse the CARP namespace (as has happened), conflicts can arise once CARP core introduces types with the same ID in that namespace.
Conceptually,
dk.cachet.carpshould be reserved for CARP core only.Should we provide functionality in CARP to fail early if platform implementers attempt to do this?
The question is where, though. It could fail on service endpoints whenever unknown types are received in the
dk.cachet.carpnamespace. But, that'd be a useless check the vast majority of time, just wasting CPU cycles (albeit neglible). Maybe it can be a warning in the list of possible deployment issues as part of evaluating study protocols?