What should the message api look like for the sink block?

[Paul Wicks]

It seems like it would be nice if the sink block could create new metadata based on received messages. What should the api surface for this look like? Should it be via a separate port? Should there also be corresponding methods to add metadata? Does it make sense to do both capture and annotation segments this way?

[Scott Torborg]

I think it should be possible to add annotations via either stream tags or messages, but for global metadata it doesn't seem like you'd ever want to use a stream tag. It might be practical to just have a single message port: if a message is received with a timestamp or sample offset, it's an annotation, otherwise, it's a global metadata key/value pair.

[Paul Wicks]

How about this:

• Add a method to the sink, set_annotation_meta(uint64_t sample_start, uint64_t sample_count, std::string key, pmt::pmt_t val). If there's already an annotation with the same sample start and count, then we add to that, otherwise we make a new one.
• Change the existing set_global_meta functions to more or less match this same signature (i.e. remove the 5 overloads and just have it take a pmt::pmt_t)
• The sink block will just have a single message port, commands
• We then just proxy these methods the same as we have done for all the other methods. So to add a new annotation, you just send a pmt message that looks something like this:

{
    'cmd': 'set_annotation_meta',
    'sample_start': 23423,
    'sample_count': 1000,
    'key': 'core:comment',
    'val': 'This is some interesting data'
}

The only other question then is whether it makes sense to have any api to create new capture segments apart from stream tags.

[Paul Wicks]

Made a PR with my proposed changes for review, see #5

[Paul Wicks]

Closed via #5