Haha fantastic
thatās good, I like it!
Good points with the narrative.
@maidsafe, can we have that crypto poem somewhere on our material? ![]()
(we need to have a significant use for the word Blocks first of course)
Haha fantastic
thatās good, I like it!
Good points with the narrative.
@maidsafe, can we have that crypto poem somewhere on our material? ![]()
(we need to have a significant use for the word Blocks first of course)
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.
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 ![]()
Doesnāt Block also somewhat implies/sounds-like with a fixed/predefined size?
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.
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):
ā¦would be suitable.
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 ![]()
@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.
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.
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.
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.
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?
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
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).
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
Ah, this discussion again
:
From Primacy of Peter - Wikipedia
⦠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).
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ā.
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 ![]()
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)
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.