Another important RFC exposing low level API from Launcher.
And 4 new Tag-types:
No.9 Encrypted Structured Data read and modified only by owner
No.10 Version enabled encrypted Structured Data read and modified only by owner
No.11 Structured Data for public read but modified only by owner
No.12 Version enabled Structured Data for public read but modified only by owner
More kinds of bricks to build the new world.
RFC PR now merged into proposed > Discuss - 0028-launcher-low-level-api · Issue #115 · maidsafe/rfcs · GitHub
In the versioned SD, does the 100KB limit apply to all versions combined or each version apart?
100KiB is the SD’s size limit. Versioned / unversioned are ways safe_core api customises the SD according to some algorithm. Users can get to even lower level and ask api to not do anything but put their data as-is and they assume responsibility about size etc. - so in this case as far as safe_core is concerned it is neither versioned nor unversioned. What all this means is that versioning/not-versioning etc has nothing to do with SD size. SD size is more fundamental - it is fixed at 100 KiB. safe_core just uses ways (e.g. versioning algos - may be linked lists of SD’s or as currently SD’s pointing to Immutable Data which stores a vector of versions) to make sure it does not produce SD of bigger sizes. That’s all.
I reviewed the proposal at Discuss - 0028-launcher-low-level-api · Issue #115 · maidsafe/rfcs · GitHub
More of a general question(s)
I always thought an SD was addressed as 512bit and 64Bit Tag (566 bits in all to address an SD)
Is this correct?
If it is then aren’t these tags really attributes. In other words would these not be great for many tags.
If I used tag 100000 for Neo’s personal C code editing, and tag 2345670-9 for Neo’s companies big project with 100 developers. Wouldn’t it be great to have say
Much better grouping using attributes rather than having to address my SDs in the address space for Tag 9 & 10 & 12
The words “tags” and “attributes” (and “traits” and anything else) are fairly vague. Yes I agree that I would like a “flag” (yet another vague word) to define versioned or encrypted instead of a specific few tags. At this point I don’t know why anyone would use a different tag if they want to be encrypted and/or versioned.
I personally am not going to worry at this point and just use their tags. If I need a concept of “tag” for my purpose, I’ll bury it in the ID.
Post is aimed at the Devs more than @cretz, but his points give the basis of the discussion
Its to do with - These tag(s) are for my/our project/app and by using a central tag for any of the 4 functions above seems counter productive and contrary to good practices. Its centralisation.
By attributes I was vaguely saying like this (SD) object is say read by owner only or is encrypted.
So the above tags could be better implemented as a permissions field (attributes) and the 4 tags would convert into
While there are more bits used, the bits can be combined to give many more options.
Are we going to add another 4 tags to allow append instead of modify to give an equivalent functionality but only allow appending. OR public append and owner modify
If we don’t address this issue at some stage then we will just multiply tags used every time a new feature is added to SD functionality. And then limit people to only using that specific tag for every SD in their project.
What about I want
But someone else decides to start a project and unknown to them my project had the above planned but only used 1/10
They decide to use similar but addresses overlapped. So now my addressing scheme has holes in it.
If I had used my own TAG instead of a centralised one then the potential of this happening is more than 2^40 times less. IE insignificant if I choose a random and non-common TAG#. But using a central TAG then the chances are much higher. (Yes I admit if I choose an ID that is random and non-common then the chance is still small, but not as small as if I can use any tag.
Actually its becoming why have tags, if I want more than owner write/public read then I have to use a specific tag#, so why even have a field called tag# since any useful use of SDs is limited to one tag#
Yes that is the solution at this time, But as with all engineering projects (physical/software) implementing the obvious the right way at the start save a whole lot of time, energy, money later on.
So now we could implement for 2 groups owners & public and later have other groups (eg primary owner)
Are we going to have 4096 tags just to implement all these and limit people to only using those system defined tags if they want some combination of the 12 “permissions/attributes”