|
Post by Admin on Sept 15, 2022 11:11:23 GMT
Please refer to attached document and consider question posed in the subject.
|
|
|
Post by Andreas on Sept 15, 2022 17:12:19 GMT
I believe that ultimately, a public open source library would be beneficial for the dissemination and adoption of MFMC. I would, however, not start such an effort too early in the process. We first need to answer the question about engineering data, and decide between compulsory information (without which a MFMC file would not be "valid"), optional information, and private custom data, and how imperative we want to be about these. These decisions impact the API (application programming interface), which should be defined in a second step. A good API is not a random collection of function calls, but follows a philosophy! The API should be published on github together with an illustrating implementation (an actual implementation done concurrently with the API definition is necessary to convince ourselves of the viability of the API) and sample files. The library should have a C-binding, which can be linked with almost anything. I would recommend to keep it a very thin layer on top of HDF5 - nothing too fancy. But, at the risk of repeating myself: I would postpone work on a library until the content questions are answered.
Andreas
|
|
|
Post by pdw1971 on Sept 16, 2022 9:52:25 GMT
I agree with Andreas that we shouldn't start the process of producing an API library until we have answered the content question.
However, the decision on whether we intend to eventually produce an API library does influence the file content question somewhat. Without a library, the easiest option for most users is for a valid file to be allowed to contain EITHER universal information OR engineering information with most users opting for the latter as it requires less work; however, with a library the universal information can be generated behind the scenes from engineering data, meaning that a file contain universal information AND engineering information with no extra effort required on the part of the user.
Paul
|
|