[RFC] Data Types Refinement

Haha fantastic :laughing: that’s good, I like it!

Good points with the narrative.

@maidsafe, can we have that crypto poem somewhere on our material? :slight_smile:
(we need to have a significant use for the word Blocks first of course)

1 Like

All you need now is a picture of dirvine in a black wolf/leather jacket riding a fire breathing dragon. (For those that have HBO, note that Drogon was the actual breaker of chains in that popular series.) I suspect @Zoki could come up with a good meme for this.

4 Likes

Seems legit to me.


Blob… Block… Blob is more recognizable / traditional for binary (large) 'object’s, IMO.

Blocks have a lot of baggage, but ignoring that I don’t think Blocks actually fit the idea of our binary data any better.

But aye, our Blob itself isn’t actually just a binary… it’s a collection of chunks, strung together by a data map, (so I agree it may not be perfect). Chunks/maps don’t immediately inspire any other naming ideas for me though :expressionless:

4 Likes

Doesn’t Block also somewhat implies/sounds-like with a fixed/predefined size?

2 Likes

yeap, from the PoV from an IT guy it’s just a binary object. It’s not inherently mutable or immutable.


But that’s not visible (at that abstraction depth) to the dev, it’s “just” a big binary “blob” & i think it’s not that important to the dev how the system is actually storing the data.

2 Likes

Yep, this.
We’re not trying to convey implementation details in the name, just what it is. i.e. an immutable piece of data, so not only a binary large object (however, the undefined size implied, is helpful communication). The comments by @jlpell is about conveying the immutability more clearly.

words with semantics of (or near):

  • Any size (so, not just large…)
  • Immutable

…would be suitable.

3 Likes

I prefer Blob to Block because Block suggests component (building block) whereas Blob suggests a whole thing. I’d like it off we can suggest immutable but docs can always say ‘immutable Blob’ enough times to associate them for Devs to pick up.

I note Josh’s early comment that I think suggests the APIs are not part of Fleming …dang! At least these parts, but that does shift my thought about what Fleming is a bit and what will remain afterwards has grown a bit in my mind.

Good discussion :smile:

@Traktion if you look at the links below the last post on a topic you should not miss stuff like this. Although I’m not sure this topic wasn’t on the front page anyway - I thought it was but might be wrong.

4 Likes

Not a big fan of block. In my mind, maps and sequences and a collection of whatever we call this. Perhaps that is where things break down a little? E.g. it implies BlobMap, BlobSequence, etc.

As we are trying to not mention what the ‘it’ is, it makes naming the singular a bit tricky! It feels like we have to describe the interaction with ‘it’.

Can we just call it Immutable, to just describe the nature of ‘it’? E.g. PublicImmutable, PrivateImmutable.

3 Likes

I plugged Immutable into a thesaurus and Perpetual came back…

Thinking some more, we would often refer to the collection or the descriptive in isolation in development. A long, float, etc, are shorthand for a long/floating point number, for example.

Storing an immutable or a perpetual could also become natural.

4 Likes

I don’t like block either, block sounds like something you staple on top of another block like LEGO. It fits with a ledger but think we should differentiate as SAFE is a total different thing. I like chunk because it sounds like just anything that is a part of something larger. Blob just sounds wrong to me, like something floating around in a aquarium.

1 Like

Really good write-up, and a necessary simplification of things, thanks @oetyng!

Took reading to the end to just about understand it, but got there finally!

One small thing that threw me off, is that (if I’ve not completely misunderstood) the list of the old data types is not in the same order as the list of new data types, and then the table of capabilities has public and private flipped, which is all a bit confusing when you’re trying to get to grips with new names!

For someone like myself without a computing background, I think the new names are on the whole good, and descriptive once I understood them (the different usage of ‘sequence(d)’ was initially confusing.)

My one big problem though is with ‘sentried.’ From a plain english point of view the connotations are too close to ‘permissioned,’ which is also a pertinent concept in relation to data on the network, but a separate one as far as I understand. Could it be just ‘concurrent?’ Would ‘ordered’ or ‘versioned’ make sense, or is that playing too loose with meaning?

1 Like

I don’t have a link, but I remember there has already been a discussion on naming of new data. Things cannot always be questioned and must be stabilized.

This list is impressive and seems complex:

But it is misleading because 2 elements don’t exist (PublishedSequencedMutableData and PublishedUnsequencedMutableData are not allowed for Perpetual Web) and remaining elements have been shortened.

The real list exposed by safe-nd is:

PubSeqAppendOnlyData
UnpubSeqAppendOnlyData
PubUnseqAppendOnlyData
UnpubUnseqAppendOnlyData
SeqMutableData
UnseqMutableData
PubImmutableData
UnpubImmutableData

Which is simpler and seems consistent to me.

Furthermore a lot of structures have names beginning with AData, MData or IData. With the new names we would lose this consistency.

Edit: Shorter names exposed by safe-nd would be even more consistent with these structures:

PubSeqAData
UnpubSeqAData
PubUnseqAData
UnpubUnseqAData
SeqMData
UnseqMData
PubIData
UnpubIData
1 Like

That’s right, thanks! Will be adding this to the list for when I update the doc.

About the names in safe-nd. Yes they have been shortened, which is what happens when names become too long or complicated. The shorts have no meaning without knowing the base for the shorts, and the base are those being changed in the RFC.

This also removes the need to shorten names into some completely incomprehensible combination of letters, which is not considered a good naming practice (although for a very long time was standard in low level coding, and still lives on among many practicioners).

5 Likes

I’d love to hear more people chip in with suggestions here.

I kind of like stone, or rock. Both bring immutability and durability to mind. Or even pebble, which is small and cute, but still immutable. And each of these is generally unique, unlike tiles which are manufactured to be identical. Along the same lines, crystal could be considered, although crystals are known to grow.

How about just Immutable instead of Blob? So instead of:

PublicBlob
PrivateBlob

PublicImmutable
PrivateImmutable

1 Like

Ah, this discussion again :wink: :

From https://en.wikipedia.org/wiki/Primacy_of_Peter#Meaning_of_"Rock"

… In classical Attic Greek petros generally meant “pebble,” while petra meant “boulder” or “cliff.” Accordingly, taking Peter’s name to mean “pebble,” they argue that the “rock” in question cannot have been Peter, but something else, either Jesus himself, or the faith in Jesus that Peter had just professed. However, the New Testament was written in Koiné Greek, not Attic Greek, and some authorities say no significant difference existed between the meanings of petros and petra

Ps rock = kepha in native Aramaic.

I learned (I think) of a BLOB (binary large object) when working with Oracle databases (before ‘The Cloud’ existed). This could be used in this context (better than block), but is not specifically referencing something immutable IMHO. Certainly if you think about another meaning of blob, like @jlpell mentioned.

And what about PublicFixed and PrivateFixed? Fixed seems to be the shortest synonym for immutable (followed by stable).

3 Likes

I like “fixed” alot, it is short and gives a clear understanding of what it implies, that it can’t be changed. Immutable feels more abstract and hard to get a grip on, especially when combined with “public” and “private”.

4 Likes

To this I would refer back to the OP:

… and say that the same applies to “Immutable”.

And I say this even though something like…

could support the argument for a less comprehensible/more arbitrary scheme.
But I don’t consider very old remnants from our programming history to be good yard sticks. Naming practices were horrible back in the days, and what has stuck has done so in spite of that, because it’s been around for a very long time now and is now the base of practically all programming.

Additionally, we are kind of inventing words and concepts if doing so, and by that I refer again to the OP:

And I would argue that our immutable blob is not that kind of remarkable / innovative thing. Rather it is something very close to existing concepts and that’s the tie we need to make IMO.


Good to hear @david-beinn!

Thanks for the observation, I will add it to the list of things to do when updating the doc.

OK, I’ll try get a grasp on what would be the majority view on that, and adjust accordingly. Thanks again for the input.

Yep. Sentried is the part I’m feeling the largest compromise is being made. Here we are partly inventing, and not being very descriptive. Concurrent was considered, it is directly landing in the right domain and using a word that is relevant, but it is unfortunately misleading and missing information. A ConcurrentDictionary in C# for example is thread safe, but it is not implementing optimistic concurrency and would not protect against that what optimistic concurrency do, which is what our Sentried flavours do. And more generally, being concurrent just means it happens at the same time, but says nothing about resolving conflicts, or how. Sentried speaks of guarding, which at least adds that little piece of information that there is a protection against conflicts.
Ordered is super overloaded and I don’t know if it adds much (but I do think that it’s not far away in usefulness from Sentried). Versioned would confuse the concept of versions which are there for both Sentried and those that are not Sentried.

All in all, I don’t think your suggestions are bad, and Sentried is not much better IMO, as I said it is much of a compromise to me.


Thanks a lot for the input and ideas everyone. Keep’em coming :slight_smile:

4 Likes

I don’t think I’d understand intuitively the meaning of ‘sentried’ in this context as it’s not a word in common usage, although the explanation does make sense.

How about ‘guarded’, ‘barred’, ‘constrained’, ‘restricted’, ‘kept’, ‘reserved’?

And for blob how about ‘slab’, or ‘lump’. (Not sure why ‘chunk’ is out TBH)

4 Likes

Chunk is not out. In fact there’s been some confusion on that part, and I’m going to come back to that soon.

Basically, ImmutableData (IData) and Chunk have been used interchangeably, as well as for different things, which actually confused me a lot up until very recently.

But I’m working on this as we speak.

1 Like