Disallow custom/extending types in CARP namespaces #461
Labels
enhancement
Nice to have, non-functional requirements.
needs discussion
This cannot yet be implemented since it requires further conversation.
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.carp
should 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.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?The text was updated successfully, but these errors were encountered: