Previous parts:
Update and DC update
In some contexts writing a blob implies deleting the old blob with the old information. In such situations it might be convenient to have an “update” transaction function that just performs both write of a new blob and delete of the old one at the same time.
We might also want to update deletion criteria for an already existing blob if someone would like to store it for longer, given a permission to affect the state of the blob. In some cases, it is not possible to determine which criterion corresponds to “longer”, so for criteria of the form “delete after X” the merge of criteria X and Y corresponds to the merged criterion “delete after X AND Y” (e.g., delete after 2 years and forever, delete after 2 years and after resource R has been created. In the first case the resource is never deleted, in the second case it depends on when the resource R was created).
Below I’m gonna describe these extra transaction functions along with the basic transaction functions in the table format for consistency for both SPA versions.
SPA v1
| TF | Description |
|---|---|
| Write | Create an SPA resource (store request), balance with a consumed ephemeral resource. The SPA resource specifies the blob to be stored and, optionally, the deletion criterion |
| Delete | Consume the corresponding SPA resource (delete request), balance with a create ephemeral resource. |
| Update | Consume the corresponding SPA resource (delete request), balance with a new SPA resource (store request). Must ensure some logical correspondence (e.g., they have the same id) to ensure it is seen as an update and not creation and deletion of two independent blobs |
| Update DC | Consume the corresponding SPA resource, create the exact same SPA resource with an updated deletion criterion that merges the two (which must be verified). This only works for SPA resources with a pre-specified deletion criterion, in which case the logic must also verify that, when the SPA resource is consumed to request deletion, the pre-determined deletion criterion is satisfied (otherwise requesting deletion by consuming the resource, always being the necessary condition for deletion, in addition to that has a higher priority over pre-specifying the deletion criterion, which can also be a valid option) |
Constraints (redundant)
| Ephemerality | TF | Constraints | |
|---|---|---|---|
| Create | Ephemeral | There must be a consumed SPA resource (ephemeral resources are created only for delete requests) | |
| Persistent | Write | There must be a consumed ephemeral SPA resource and the blob is valid | |
| Update | There must be a consumed persistent resource in the same action that is a previous version of the “same logical” blob (same-ness here is identified by some blob id or some other parameter that indicates that these blobs are not independent[1]). | ||
| Update DC | There must be a consumed persistent resource in the same action that contains the same blob and includes a deletion criterion that corresponds to a part of the self resource deletion criterion (DC1) | ||
| Consume | Ephemeral | There must be a created SPA resource (ephemeral resources are created only for write requests) | |
| Persistent | Delete | There must be a created ephemeral SPA resource and the blob is valid | |
| Update | There must be a created persistent resource in the same action that modifies the “same logical” blob (same-ness here is identified by some blob id or some other parameter that indicates that these blobs are not independent[1:1]). | ||
| Update DC | There must be a created persistent resource in the same action that contains the same blob and includes a deletion criterion that corresponds to the self resource DC (DC1) merged with another deletion criterion (DC2) |
SPA v2
| TF | Description |
|---|---|
| Issue | Create a ticket, balance with ephemeral |
| Write | Create an ephemeral SPA resource containing the blob and the DC. Balance with an SPA ticket [2] |
| Update | For SPA v2, we don’t need to have an explicit update function since the deletion criterion is specified upon creation and is triggered independently. In particular, it might directly require to be deleted when a newer version of the same logical blob is created. The same mechanism can be assumed for SPA v1, if the deletion criterion is specified in advance. Nevertheless, the deletion must be explicitly triggered for SPA v1 resources. |
| Update DC | Since deletion is triggered automatically for SPA v2 resources, there is no natural way to update the deletion criterion for such resources within the existing definition of the SPA v2. Therefore we extend the definition of SPA v3 to include the DC update mechanism. To update the DC, the user creates an ephemeral resource that includes the key under which the blob is stored, the blob itself, and the updated deletion criterion |
Constraints (redundant)
| Ephemerality | TF | Constraints | |
|---|---|---|---|
| Create | Ephemeral | Write | The blob and DC are valid, there is a balancing SPA ticket |
| Update DC | The blob, DC, and blob key are valid, there is a balancing ephemeral resource | ||
| Persistent | Issuing SPA ticket. There must be a balancing ephemeral resource, the issuing party is authorised to issue the ticket | ||
| Consume | Ephemeral | Issue | There must be a valid SPA ticket created |
| Update DC | There must be an ephemeral SPA resource requesting a DC update created | ||
| Persistent | SPA ticket. There must be an ephemeral resource requesting a write (blob, dc) created in the same action |
We can see that the SPA v2 has simpler logic, as before, but the DC update requires an explicit modification to the design. It might become even simpler if we get rid of the ticket system and only keep the ephemeral request part
optimising independent blob writes and deletes this way should be logically separated from a blob update, we need to distinguish between updates and optimisations explicitly, otherwise it is possible to break the update. For now, I do not include optimised write-delete transaction functions ↩︎ ↩︎
Actually I just now realised that the whole SPA ticket system is unnecessary and we can just use ephemeral resources to request storage (corresponds to the second half of the initial SPA v2 diagram, with SPA ticket replaced by a regular ephemeral resource). Maybe I’m going crazy now and missing something, but if not, the design becomes significantly simpler ↩︎