Open jacobagilbert opened 1 year ago
There are a few possible ways I can think to accomplish this, and none of them are especially nice:
core:streams
object. In addition to name
we could add collection
and archive
. This is somewhat annoying since including more than one of these immediately becomes ambiguous and we have tried to avoid situations where "only one of the following fields can be defined".name
so it can be either a .sigmf-meta
file name (overload behavior of base-name
but require the full filename + extension), or a .sigmf-collection
file name (and the hash
would be over the collection metadata, which would in turn cover sub-collection recordings/collections hashes ensuring validity of the recursive integrity check), or a .sigmf
archive. Archives are a little more complicated since its not clear what exactly should be hashed (there can be more than one metafile inside); we could simply hash the entire tar archive and deal w/ the associated complications of that. Fallback behavior (no .sigmf*
extension) would indicate a Recording base name.name
and use a new field for this.
Currently SigMF Collections define the sigmf recordings contained in the collection by specifying the basename to the SigMF Recording, which necessarily is the same for both sigmf-data and sigmf-meta files in the Recording.
This is limiting in that one cannot specify Archives (of Collections or Recordings) or Collections as members of SigMF Collections, which has a variety of valid use cases (e.g.: #271).
This issue seeks to gain consensus around the idea of redefining SigMF Collections such that they can include [sub]Collections and/or archives.