From: Stephen S. <rad...@gm...> - 2013-04-08 15:20:50
|
Merged. But I am left wondering if we should think about a more generalized options mechanism... currently it's a messy combination of a variety of constructions + these binary flags. Don't know, perhaps binary flags will suffice for the future but it's hard to tell.. what if we need an integer parameter in the future, or something else? Maybe string-based option identifiers, taking a void* as parameter? Now's the time to think about this, since the lo_address_set_flags was also not in 0.26. lo_server_set_option(const char *option, void *param); where for the coercion flags, it could be called, lo_server_set_option("coercion", (void*)0); This would allow for integer or even string/struct parameters in the future. But I'm not sure what use cases it would be for, so I'm not sure whether it's necessary or not. Steve On Tue, Mar 26, 2013 at 7:11 PM, Stephen Sinclair <rad...@gm...> wrote: > On Tue, Mar 26, 2013 at 6:47 AM, Camille Troillard > <ca...@os...> wrote: >> Talking about lo_address_set_flags, I have a couple of questions ... >> >> It seems lo_address_set_flags is not public, is it intentional? > > Nope, thanks for pointing that out. > >> Also, the flags type for lo_address_set_flags is named lo_proto_flags, shouldn't we rather name it lo_address_flags? > > Yes, perhaps. I had only used it for details about the protocol (i.e. > which stream type to use) so I was calling them "protocol flags", but > you're right, perhaps they are "address flags". > >> Finally, it would be nice to provide a name for the uninitialized flag, for example LO_NOFLAG=0x00. > > Sure, I don't mind either way. > > cheers, > Steve |