Hi Kostis - 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? > > 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. >
Not a bad idea. It might be worth getting Johnathan to weigh-in on what he thinks is best, here, too. > - 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. > > 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? > For discussion of the SigMF design, the SigMF tracker is the right place. For discussion of your GSoC proposal, I think staying on-list is the right thing =) > - 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. > > According to the description in the main page, RapidJSON "is > self-contained and *header*-only". I dont know if MIT is a problem though. > MIT license is fine . Cheers, Ben
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
