Closed glindstedt closed 4 years ago
I guess it would also clarify the API, so please give it a try but open another PR for this change.
Sure thing, I'll give it a try
I am ready to merge and release a 0.3.1
if you're okay with it?
Yes definitely, go ahead. Although crates.io says 0.4.0 is the latest?
After looking into potential refactoring I'm not convinced myself that there's much benefit, although I would probably rename read_bundle_element()
to read_bundle_element_content()
for clarity
Although crates.io says 0.4.0 is the latest?
You're correct, I will have to check why I did not push the 0.4.0
tag.
After looking into potential refactoring I'm not convinced myself that there's much benefit, although I would probably rename
read_bundle_element()
toread_bundle_element_content()
for clarity
Sounds fine to me, will rename it sometime this week.
I renamed the function and released a v0.4.2
since this is part of the internal API.
Nice 👍
From the spec at http://opensoundcontrol.org/spec-1_0
I discovered this wasn't supported in the wild where a specific OSC plugin for a DAW seems to be using empty bundles as heartbeat messages, which would cause the library to panic.
The function names in the code seem to reflect some confusion around the "Bundle Element", the
read_bundle_element()
function for example reads the contents of the element, but the way I interpret the spec is that an "element" is the tuple (size, content). If you think it's worth it I could try to refactor theread_bundle_element
andread_bundle_element_size
functions to match this, just to align code structure with spec concepts.