search

kivy / oscpy

An efficient OSC implementation compatible with python2.7 and 3.5+
MIT License
109 stars 27 forks source link

bind_all and unbind_all methods for OSCThreadServer... #55

Closed markkorput closed 4 years ago

markkorput commented 4 years ago

…to let caller register callbacks that receive all osc messages.

I've been really with oscpy so far, but I was missing the option to register more address-agnostic callbacks. When dealing with highly dynamic set of OSC address endpoints, it's good to have the option to leave address-matching to the caller. This implementation adds support for that.

I would have added tests, but I couldn't figure out how to run the tests so I had to resort to manual testing.

tshirtman commented 4 years ago

https://github.com/kivy/oscpy/issues/3 allowing the user to define a "catch all" handler has been discussed previously, and the "default" has been added for this case. It did seem better to be "either/or" (either you manage all through the called method, to do all your dynamic routing, or you use pattern matching like currently), and not to encourage users to have multiple callbacks for the same message, rather than going the way you did.

Is the current way (just using default, and no custom handler at all), not enough for you? can you clarify why? Maybe it's just a matter of documentation?

I don't think it would be good for users to register multiple "bind_all" methods, and to to post-filter in them, that does sound like an anti-pattern we should not encourage.

markkorput commented 4 years ago

Hey @tshirtman, I didn't know about the 'default' handler option and I guess I missed it in the code as well, but reading through #3 it does sound like that would work for me, thanks!

My case is to be able to receive configuration input for a dynamically. Changing set of parameters, explicitly binding and unbinding exact address handlers for appearing/disappearing parameters is simply more complex and because the internal lookup logic is already available, accepting all OSC messages and performing lookups internally is the desired approach, at least for the currebt state of development.

Anyway, I'll probably switch to the default handler when I have time to look into that, thanks for responding!