EPHEMERALITY and data-persistence?

One way this used to be done was chaining and easy enough to apply generically to MDs. Methods to work with limits on storage abounded in the days when main memory was measured in KWords cache was a drum of a couple MWords and each disk in <40MWords

So your data object could be of variable size since you want to allow for data types that contain blobs of no fixed size, would be a series of MDs.

The first MD of the data object would have an address (probably stored in an index scheme) then the address of the second is stored in a field of the first MD. The 2nd and thereafter MDs do not need a set address or tag type since they are linked to from the one before.

In Fact you could have the 1st MD also contain links to (addresses of) all the chained MDs and if you have too many then chain that too.

Thus the first MD of the data object contains fields. And if more than one MD needed then the 2nd and subsequent ones are chained. The data object starts on the 1st field after the links (addresses). And you could even have the elements in the data object as fields too and include an index of where each element is after the links (addresses) but before the 1st part of the data object.

1st MD of single data object requiring “n” MDs with “x” elements

  • field 1: address of next MD
  • field 2->n: (n-1) addresses of MDs 2->n
  • field (n+1) → (n+1+m): addresses of MDs containing the start of the corresponding element
  • field (n+1+m+1): 1st element of data object.

And when there is not enough fields and/or space continue the fields in the next MD. Each MD has the 1st field as the link (address) to the next MD in the data object chain.

This way the indexing of your data objects only points to one MD for each data object and then the data object is its own series of MDs with self contained indexing.

2 Likes