# Pulp 4 breaking change ideas

## Removal of pulp_href support

The "prn" will be the only way to reference an object in Pulp.

## Switch all installations to domain-enabled

Goal: To convert all non domain-enabled installations to domain-enabled installations.

Why with Pulp4?
* To switch from a non domain-enabled installation to a domain-enabled installation your URLs will have to change.
* With Pulp4 URLs will have to change anyway (replacing `/v3/` with `/v4/`)
* So now is the perfect time; have users switch to the `/v4/` URL that is domain-enabled

## Retain Repo Version defaults to 1

Goal: By default Pulp doesn't have repo versions enabled, most users don't use them

Why with Pulp4?
Because it's a default change

## Stop calculating SHA224, SHA384, SHA512

Goal: to speed up the sync and upload times

These other hashers would still be calculated if it's needed to validate correctness, e.g. the RemoteArtifact uses one of them.

Why with Pulp4?
These digests are user-visible in various APIs so if we drop calculating them, while not a breaking change, it is a breaking data-quality change.

Here's a [script measuring the additional cost of hasher computation](https://gist.github.com/bmbouter/bb99b3b66899ae3bdff9df6ca1fdfe4b). It shows the `update()` calls add significantly more time, e.g. the following table:

+------------+-------------------+-------------------+
| Hash Type | update() Time (s) | hexdigest() Time (s) |
+------------+-------------------+-------------------+
| SHA-224 | 34.696041 | 0.000011 |
| SHA-256 | 34.337533 | 0.000003 |
| SHA-384 | 24.644826 | 0.000003 |
| SHA-512 | 23.191746 | 0.000002 |
+------------+-------------------+-------------------+

## Removal of in-database Access Policies

The access policies should be configurable as a usual setting. Making them available in the API was probably never a good idea.

## Improve resistance against internal / external package confusion

https://github.com/pulp/pulpcore/issues/1969

## Notification system to work with some API requests (today it works for task status)
This could be useful for devops teams to create automation... some examples:
- trigger a pipeline execution in case of a resource update
- if a repository is created verify if it is allowed (based on an internal business logic, for example quota)
- send an email if a distribution is deleted

## Task being scheduled to a "worker" (node) based on labels
allows service providers to have dedicated workers for customers

## A garbage collector
- orphan cleanup
- reclaim disk space
- repo version prune?

## Removal of Artifact APIs

## Move APIs to within plugin URL namespace

* Instead of /pulp/api/v3/rpm/rpm/repositories/ (etc.), do /pulp/api/v4/rpm/repository/rpm/
* Gives each plugin more space for providing their own custom APIs