cimbi
commented
5 years ago Hi level APIs can be found in: https://github.com/msel-source/mefreader https://github.com/msel-source/mefwriter
Closed vkremen closed 5 years ago
cimbi
commented
5 years ago Hi level APIs can be found in: https://github.com/msel-source/mefreader https://github.com/msel-source/mefwriter
Hi, We have been working with the MEF library for about a year now. We appreciate the library was already ported to Windows which greatly simplified our task however I’d like to ask a couple of questions:
We have been constantly stumbling across small issues which most of them we were able to work around in our in-house C# wrapper for the library. I sent 3 patches for the original library back to you via e-mail as well. What are the future plans for incorporating these patches to the original library and for the future releases of MEF 3 library? Is a bug-fix release planned? The operation of opening data writes temporary files. Although the temporary files should have unique names they are created in the directory structure of the MEF data directory. Therefore users need to have write permissions to the disk just to open and read the data which can later cause security issues. Are there plans to change it? The desired functionality can be achieved without writing temporary files at all. The wrapper for the Python 3 language is effectively based on a different code base. This can later cause compatibility issues especially if the Windows and POSIX versions of the MEF library are not merged together and the code is not covered by a set of automated tests. What are your plans for future support of both Windows and POSIX versions and for testing the library? Since the MEF library does not support any validation except a CRC check we are not able to tell users whether files they want to open are correct or what is wrong with them. Sometimes a defective file causes invalid pointers leading to an Access Violation Error or a SEGFAULT. In such case our application simply crashes (the operating system kills it immediately) without any chance of telling users what went wrong. Can a validation routine or a proper error handling be added to the library? The MEF library API is overly complicated and impossible to use without knowing the internals of the format. This is a bit unfortunate since it causes difficulties when working with an otherwise perfectly fine file format. It also causes a lot of unnecessary movement of data in memory through the “Berlin Wall” dividing the manually-managed heap for the C library and the garbage-collected heap for the C# GUI or the Python scripts. For instance, there is no easy way of obtaining data for a particular time range. Ideally, this could be a single call instead of obtaining RED blocks for each signal, ordering them (because they can be out of order), decoding each of them and constructing the signal to be displayed. APIs are written once but called many times. Do you think that a high-level API can be added in a near future?
We fixed some of above things in our modified version of meflib and we suggest to include those into next meflib build. For simplicity we logged this under #1 and #2 issues.
We really appreciate the features the MEF format has over e.g. HDF5 and are looking forward to the minor glitches being resolved.