Closed svenstorp closed 7 years ago
How about storing moves in the clock's native format? That should be pretty space efficient and all the code needed to interpret it is there already.
Pros and cons (without valuing them) about using clock's native format: Pros:
Cons:
Pros and cons (without valuing them) about using compressed XMLs: Pros:
Cons:
Thanks for adding the pros and cons! I think that the preserving unknown log data for later is a big plus.
I would treat this as a storage format for the clock owners. They would need libambit
anyway to get their data off the clock. If they want to "export" to something else like XML, that would not be too hard then. The export can then be used as input to things like the GPX Python script.
Different native formats can be dealt with by storing clock/model information with it. This kind of metadata can be put in a header to the log data.
Performance issues? That's something that has to be borne out in practice. It's not like XML processing is a speed monster.
Closing issue without any recent activity. Feel free to reopen if issue is still relevant.
Today all synced moves are stored as XML-files in ~/.openambit. Those XML-files are pretty space consuming, typically > 2 MB / hour of exercise. XML was chosen since it is easy to read, and compare to Moveslink. Possible options: