life-cycle management
A Collection maintains Units of information. Units with various
content. These Units do not simply appear and disappear as files in a
directory: they have a life-cycle; they enter via multiple steps
before they are visible, and may make remove themselves with a plan.
Unit State mechanics
The Collection (~managing process) will "run" the cycle for each Unit.
In some cases, it will need to inspect the content of the Unit to change
its state. Also, Collection managers can influence the state of the
Unit within the Collection.
Put yourself in the role of the Collection manager. You need to get
the Unit in a distributable state (usually Published), and clean-up
later. Any single Unit may go through each of the states below, from
top to bottom. However, many states MAY be intermediate States which
are skipped immediately.
Not all state transitions have equal means. The Collection Rules
can be modified to adjust behavior. For instance, the Rule MAY put
an automatic expiration on an incoming Unit. The Rules MAY also determine
that the Collection managers have to agree on state transitions via the
voting mechanism.
You may upload a new revision of the same Unit. For instance, when
you want to set a deprecation of expiration date. The new Unit will
transition step-by-step to reach the same UnitState as the original Unit.
When it reaches that state, the original Unit revision will be removed.
The discovered changes are logged.
The Unit States
The states below are in "natural order", which means that the Collector
will default in facilitating transitions from top to bottom. However,
this pattern can be influenced in various ways.
| ms:UnitState |
Purpose and configuration |
|---|
| Free |
This is a condition: there is no Unit with a specific name.
|
|---|
| Reserved |
The client would like to upload a certain Unit, which may still
need to be created. At first, the client requests to be allowed
to use a certain name.
The reservation request is a partial Unit. It may already specify
authors, owners, unit type, size, etcetera. Probably, it does not
contain a payload.
The Collection Rules may refuse to reserve the name. For instance,
some of the provided conditions already fails. Of course, it is
better to fail before the upload than after. The Rules may require
a vote from a Collection owner to progress, for instance to manually
ban unpleasant names.
The Constitution Rules may specify a relative expire time. The Unit
may contain an absolute moment of expiration. Whichever comes first
will expire the reservation.
|
|---|
| Uploaded |
Without explicit name reservation, you can upload the Unit. Of course,
all Collection Rules are checked whether the Unit name and Content are
allowed.
|
|---|
| Verified |
The Collection may want to verify the payload of the Unit. Does it
match the unit type? This might be expensive. Clients which use the
content SHOULD not trust the content as well. The server which runs
the Collection has hooks which enable you to add your own validator.
|
|---|
| Accepted |
To reach this state, the verified Unit is up for voting. The voting
Rules MAY require confirmation from one or more people from certain
Identity groups, the Owners, or Authors. The people which are allowed
to vote have access to this Unit.
When Accepted, it may need to wait before it gets Published. Some
clients may have access (for instance Collection replicators), but
special rules apply.
|
|---|
| Published |
When the publication date has passed (defaults to 'now'), the normal
client access rules get into effect. This is the state you expect
the Unit to be in for most of its existence.
|
|---|
| Deprecated |
On an absolute date, which is pre-specified in the Unit, its use
MAY get deprecated. This typically comes with some explanation.
The usual access rules do still apply. The Client may warn the
User.
|
|---|
| Expired |
On an absolute date, which is pre-specified in the Unit, use gets
restricted to the owners of the archive. Clients MAY warn users
before expiration.
|
|---|
| Withdrawn |
This Unit MUST not be used anymore. It will contain a reason for
this, for instance legal take-down requests. This state is more
serious than removal of the Unit: it reflects the instruction to
clients to remove its effects immediately.
|
|---|
| Blocked |
The Unit does not exist anymore, and cannot be recreated until an
provided absolute date or relative time span in the Rules.
Owners of a Collection SHOULD be able to push any Unit into Expired,
Withdrawn or Blocked state.
|
|---|
| Free |
The name of the Unit is reusable for a different Unit.
|
|---|
mark@overmeer.net
Web-pages generated on 2023-02-03
| 
