For certain use-cases, we will need some way of storing metadata along with values that we store in keyvalue instances.
(As a stop-gap solution in the past, we have occasionally stored a separate '_info' key alongside every value that needs metadata, but that's non-optimal for multiple reasons.)
Ideally, the metadata for each value would be:
Optional.
Easily posted simultaneously with the value.
Stored contiguously with the value within the database.
Not returned by default for an ordinary .../key/... call.
If we choose to implement this feature using protobuf, then a protobuf-based read/write API could be exposed for powerusers. But either way, a "simpler" API based on pure HTTP will be needed for naive clients who won't want to get their hands dirty with protobuf. Possible "simple" implementations could include:
Provide separate endpoints for reading/writing metadata and binary value
Allow metadata to be read/written via the http headers (e.g. base64-encoded)
Allow reading/writing metadata and binary value as a tarball containing a meta.txt file
For certain use-cases, we will need some way of storing metadata along with values that we store in
keyvalueinstances.(As a stop-gap solution in the past, we have occasionally stored a separate '_info' key alongside every value that needs metadata, but that's non-optimal for multiple reasons.)
Ideally, the metadata for each value would be:
.../key/...call.If we choose to implement this feature using protobuf, then a protobuf-based read/write API could be exposed for powerusers. But either way, a "simpler" API based on pure HTTP will be needed for naive clients who won't want to get their hands dirty with protobuf. Possible "simple" implementations could include:
meta.txtfile