Re: [liblo] Pattern matching in server methods

From what I remember (it’s a few years ago now!) the intention was that you register the same handler for multiple paths:

lo_server_thread_add_method(st, "/channel/*/mixer/audio/1/dBFS", "f", mixer_handler, NULL);
lo_server_thread_add_method(st, "/channel/*/mixer/audio/2/dBFS", "f", mixer_handler, NULL);
lo_server_thread_add_method(st, "/channel/*/mixer/audio/3/dBFS", "f", mixer_handler, NULL);
…

As someone else said, the wildcards are for incoming messages, not handlers. You can’t do wildcard-to-wildcard matching, obviously.

When the handler is called, it’s told what path it was called from. If you want more context, that’s what the user_data field is for - you could pass in a pointer to the channel number to save you parsing the path for e.g.

- Steve

> On 28 Sep 2015, at 23:12, Carl z! Zwanzig <zb...@so...> wrote:
> 
> Hi,
> 
> On 9/28/2015 12:24 PM, Erik Ronström wrote:
>> In the original OSC spec, pattern matching is used the other way round:
>> handlers have absolute paths, while messages can use wildcard paths, in
>> which case they are dispatched to all matching handlers.
> 
> Actually, I wasn't aware of that (will have to look at the spec again). The 
> code (server.c, dispatch_method) has a check as to whether the path contains 
> a wildcard character:
> 
> 1711:    int pattern = strpbrk(path, " #*,?[]{}") != NULL;
> 
> but it's not clear to me whether this is the path out of the received 
> message or as defined to lo_server_thread_add_method.
> 
> 
> Anyway, is there a better way to do this? I'd like to have one handler that 
> gets all "/channel/*/mixer/audio/*" messages and another that gets 
> "/channel/*/stage/layer/*/*" messages. My workarounds are to either separate 
> them in a single handler or add separate handlers for each message, which 
> seems inefficient.
> 
> Thanks,
> 
> z!
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel