Confusing endian handling

jsimonetti / go-artnet

This package attempts to implement the Art-Net 4 specification from (c) Artistic Licence Holding Ltd.

MIT License

33 stars 20 forks source link

Confusing endian handling #8

Closed aklinkert closed 5 years ago

aklinkert commented 5 years ago

Within the artpoll, artpollreply, header and packet files the opCode is converted from little to big endian and vice versa multiple times which makes it pretty confusing during development and debugging to understand when and why the conversion is done. I tried to start cleaning that up but wanted to hear your opinion on that before putting too much effort on that, as I would lean to refactor and centralise the generic packet handling. So, any thoughts on that?

jsimonetti commented 5 years ago

To be very honest, I dont rember the ins and outs of opCode anymore. I seem to remember that opcode has different endianness for some packets. I will have to take a look at the binary spec again to know what is was about again.

If you can simplify then I am all for it. If you wish to bounce ideas Id be happy to help.

If you are interested, me and several excellent developers hang out in #networking in the Gophers Slack, https://invite.slack.golangbridge.org/

jsimonetti commented 5 years ago

Would you consider this issue resolved with #10?

aklinkert commented 5 years ago

Yes, definitely. The endianness handling now limits to validate and finish method of each header.go and artpollreply.go, and the artpollreply.go has explicit comments stating why we have to handle it separately. 💪