On Sun, 2007-09-23 at 22:36 +0200, Arnold Krille wrote: > Am Sonntag, 23. September 2007 schrieb Ken Restivo: > > Does OSC support "reflection"? i.e., is there any way in OSC to interrogate > > a device and get back a list of all available parameters that the device > > supports? > > OSC is connectionless, at least if the implementation uses udp as the > transport-protocol (which most do). So there is no real way to even return > values. Most apps send return-values to the host/port the query came from, > but if that fails or is not handled (as the current state of ofqf...), > nothing really happens. > Thats already quite a problem, introspection/interrogation is totally up to > the dev writing the app you want to control. > > I would propose some basic "/introspect" to send back some kind of textual > representation of the tree of options that is handled by the app. But its up > to every programmer to implement this. And then we still have to negotiate on > a format for the answer... (/me is voting for some xml: <path > name="bla"><path name="first" ><argument type="int" /><argument > type="string" /></path></path> :) D-Bus does this - it is basically OSC + better RPC structures + introspection + a bus daemon for discovery. All D-Bus objects (are supposed to) implement the Introspect method, which returns an XML representation of that object with all its interfaces, methods, signals, properties and child objects. But I've never understood why they use XML-in-a-string for that when they already have a nice message format. --ll
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
