Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reader: decode message by message #17

Open
ktye opened this issue Jul 24, 2016 · 4 comments
Open

reader: decode message by message #17

ktye opened this issue Jul 24, 2016 · 4 comments

Comments

@ktye
Copy link

ktye commented Jul 24, 2016

Can you decode messages in a loop, instead of decoding the whole file in on call?
An application is a corrupted fit file, where you want to extract all record messages that are available.

@tormoder tormoder added this to the Unplanned milestone Jul 30, 2016
@tormoder
Copy link
Owner

Hi, thanks for your interest in the library. I don´t have time at the moment to make any major changes, but would be happy to take any contributions.

I don´t think it´s possible to have a generic decode-one-message-at-a-time function, since the messages can be of different types. A function could return an interface{}, but the the user would have to type cast them, and that would not be a good solution.

I have not looked in detail on how to official SDK does this, but I think it uses some kind of message listener for each message type a user is interested in. It may be possible to be something similar for Go, where a user could subscribe to the messages they are interested in, and receive each type of messages on separate channels. The user could then process them in a for-select-loop.

A more manageable fix would be to change the semantics of the Decode function, and return all messages seen before any decoding error occurred. Now the decode function returns nil if there is any error, but this could be changed to be any successful decoded messages seen before the error.

@ktye
Copy link
Author

ktye commented Jul 31, 2016

I think returning an empty interface is OK. I see no other way.
You will process the messages in a type switch. Types which you are not interested, you will not implement. This is similar to registering them in the first place.
It has more applications than just corrupted files, it allows to get the messages in the order they appear in the file.

Anyway it's a great package and I know the effort it must have taken to implement, as i was trying to do the same. I stopped and use yours now!

@tormoder
Copy link
Owner

I forgot about the order of messages; that is a good point.

@tormoder
Copy link
Owner

I suppose this is related to encoding (#1) as well, if the goal is a byte-for-byte equal result after a decode-encode round trip.

@tormoder tormoder changed the title Decode message by message reader: decode message by message Apr 3, 2017
@tormoder tormoder modified the milestones: Unplanned, fit release 0.5.0 May 10, 2019
@tormoder tormoder modified the milestones: fit release 0.5.0, Unplanned Jan 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants