RFC 42 – SAFE Launcher API v0.6

safe_launcher
safe_core

#21

Displaying the version number has many usage:

  • version 0 shows that the object has never been modified since its creation

  • version > 0 indicates the number of times the object has been modified (for example it could be the number of edits of a post)

But these properties are only true if SD deletion is implemented by storing an empty payload and incrementing the version, like previous implementation (see Deletion of SD objects topic).

I am sorry to insist, but it seems so obvious to me.


Transparency or opacity of SD modifications
#22

If I understand correctly, we have to do the following steps to read a SD:

  • get identifier handle with POST data-id/structuredData

  • get SD handle with GET /structured-data/handle/{DataIdentifier-Handle}

  • read SD data with GET /structured-data/{Handle-Id}/{Version-Number}

  • drop SD handle with DELETE /structured-data/handle/{Handle-Id}

  • drop identifier handle with DELETE data-id/{handleId}

I don’t see how the Get DataIdentifier handle for Structured data end point is used (GET /structured-data/data-id/}{handleId}). Maybe this section has to be deleted from structured_data.md file because the functionality was moved to data_identifier.md?

Edit: added handle drops.


#23

Have updated the PR with the inclusion of version fields. data-version key is used to represent the data versions for tag type 501 and version key is used for the SD’s version field.

When a StructuredData is created, the structured data handle is returned in the response and not the DataIdentifier handle.
This function will help in obtaining a DataIdentifier handle using the existing StructuredData handle.


#24