deprecate tuples as collection Recording pointers #239
Conversation
|
@bhilburn collections support is ready for libsigmf, but it needs this specification change - can you take a look and provide thoughts? |
bhilburn
left a comment
There was a problem hiding this comment.
@jacobagilbert - I like this proposed solution. Good idea / design. My comments are all copy related, not design related.
|
Bumping, looks like no changes since last review |
567d03d to
d95db9c
Compare
|
@bhilburn thanks for the ping. I think I have addressed most of the feedback. I also did a quick scan through this for |
45c86e8 to
89fb246
Compare
89fb246 to
4a99554
Compare
| ], | ||
| "antenna:hagl": { | ||
| "name": "hagl-basename", | ||
| "hash": "9c1ab7285c13644cef5d910dc774ca63d1921f91318417cfadc71c4d7f3acf85ec3c5b05e9335e9cc310b1557de517519c76da540b08886a0e440d71e1271fd0" |
There was a problem hiding this comment.
All these example hashes were previously sha256 but the spec calls out sha512, fixed.
4a99554 to
8ddda7d
Compare
bhilburn
left a comment
There was a problem hiding this comment.
Minor language comment, otherwise this PR is great and is the best way forward for this issue IMO.
8ddda7d to
fcde174
Compare
in favor of JSON objects, avoiding nested vectors (flatbuffers limitation) and also permitting expansion within this object.
5efad4c to
5621307
Compare
|
Issues addressed, multiple approvals. Merging. |
This is done in favor of JSON objects, avoiding nested vectors (prohibited by flatbuffers) and also permitting expansion within this object.