|
From: | Ben Hilburn |
Subject: | Re: [Discuss-gnuradio] [GSOC17 - Draft proposal] Implement SigMF functionality for GNU Radio |
Date: | Wed, 29 Mar 2017 10:25:17 -0400 |
Maybe I could let the destructor of the block in combination with fseekm handle the finalization of the metafile. The case of segfault is actually a question that needs more attention.So the SigMF spec is designed specifically to enable writing the metadata and dataset files in a streaming manner. The spec is careful not to dictate how applications create SigMF recordings, so it's not a problem if you write a bunch of stuff and then after you finish streaming to the files you open them up and add some more stuff to finish them off.Bastian's point, though, is a good one. In the use-case where you are streaming metadata and samples into files and then you close your application, do you plan on needing to go back to add more information to the metadata file? If so, how do you do that in an automatic way if the flowgraph has stopped?
I have already started looking at the open issues. Do you think it would be meaningful to move the discussion there, in a dedicated issue?- We are working hard to get the SigMF spec into a stable state as soon as possible, but as you can see from the issue tracker (which is where we are hosting our discussions) there are aspects of the spec that are still being debated. Many of these would impact your implementation. I think it would be good to explain your plan to (a) participate in the SigMF spec discussions, especially with the insight you gain from implementing support for it and (b) deal with pieces of the spec that may be a moving target.
According to the description in the main page, RapidJSON "is self-contained and header-only". I dont know if MIT is a problem though.- Since this will create a dependency on RapidJSON (or whatever you use), we'll want to be sure that *not* having that installed doesn't prevent building anything not related to SigMF within GNU Radio. I really dislike adding dependencies, but since we don't already have a JSON library there isn't much of an option, here, so we just need to be sure to minimize the burden to users, developers, and packagers.
[Prev in Thread] | Current Thread | [Next in Thread] |