This is a digression on a note on apartments
This issue has been discussed several other places already.
We attempt to discredit a few naïve theories of names here
and here we propose hashes of file content as the ultimate name.
We may compute the hash of data that arrives at a machine to become a new tenant.
If new tenant B can insist on the correct hash for tenant A whose local services he requires, and he is already confident of the platform where he runs, then he can count on the quality of the service from A.
Tenant B may also be satisfied by a certificate to the effect that a service is provided correctly.
A new tenant may even not be picky and take whatever local service goes by some well known service name, but I hope that this does not become the norm.
There is a user interface problem here.
The protocols I have described here assume that if A depends on B then B is older than A.
This does not support upgrading the lower level service, B.
Upgrading lower level middleware is, of course, where much grief arises in today’s systems.
Yet it must sometimes be done.
An example is moving from PPP to some new style protocol.
Old trusted browsers should be happily accommodated without disruption.
There are at least two problems here:
- The new service may indeed be incompatible with the old.
- The service instances have long term state.
The first problem can be addressed by specialists with reputations to protect and that vouch for compatibility.
Tools must be devised so that such specialists can apply their magic, and be paid.
The second problem of accommodating new behavior to old state is difficult.
Solutions that I know are some combination of kludgy, insecure and ungeneral.
In some systems an object may be designed to adopt a new behavior that is not defined when the object is created.
This leads to the state being older than the behavior, the opposite of so much of the technology.