Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disallow custom/extending types in CARP namespaces #461

Open
Whathecode opened this issue Mar 2, 2024 · 0 comments
Open

Disallow custom/extending types in CARP namespaces #461

Whathecode opened this issue Mar 2, 2024 · 0 comments
Labels
enhancement Nice to have, non-functional requirements. needs discussion This cannot yet be implemented since it requires further conversation.

Comments

@Whathecode
Copy link
Member

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?

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?

@Whathecode Whathecode added enhancement Nice to have, non-functional requirements. needs discussion This cannot yet be implemented since it requires further conversation. labels Mar 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Nice to have, non-functional requirements. needs discussion This cannot yet be implemented since it requires further conversation.
Projects
None yet
Development

No branches or pull requests

1 participant