On 10.07.2017 17:15, Tanu Kaskinen wrote: > On Sat, 2017-07-08 at 22:40 +0200, Georg Chini wrote: >> On 07.07.2017 16:12, Tanu Kaskinen wrote: >>> On Thu, 2017-07-06 at 21:35 +0200, Georg Chini wrote: >>>> Looks good but does not really answer my intended question. Let me >>>> ask differently: How should the recipients be named? >>> If the recipient is an object as I originally intended, then the object >>> name could be used (e.g. sink name). If the object doesn't currently >>> have a name (e.g. sink inputs), then I think a name should be added. I >>> think it would be good to have names on all objects, as long as they >>> are more informative than just the object index. >>> >>> If the recipient identifies just the implementor of a collection of >>> functions like you suggest, then the name should be something suitable >>> for that. For example, the loopback API could be named "loopback". I >>> don't want to use "module-loopback" as the name, because the API may >>> not be forever provided by a module called that. Loopbacks could very >>> well end up being included in the core, or loopbacks could be provided >>> by a library that is used by other modules to create loopbacks without >>> needing to load any module-loopback instances. Loading and unloading >>> modules and then controlling those modules from policy modules is more >>> cumbersome than using a direct C API like pa_loopback_new() and >>> pa_loopback_free() and pa_loopback_set_foo(). >> I do not really see the difference in that case. The "implementor >> of a collection of functions" is an object. If we allow any object >> to register a message handler, a module is as valid as an object >> as any other entity. I was just saying that I do not see the need >> to chain message handlers if each object registers its handler >> under a unique name. A handler for object A may contain functions >> that operate on object B if these functions are specific for object >> A. If they are not specific for object A, they belong to the handler >> of object B in the first place and should not be implemented together >> with object A. > I'll comment on this topic later in this mail. > >> Regarding your naming - I don't see why we should not use module-xyz >> as a name. As said above, a module is a valid entity and as such entitled >> to register its own handler. When the functionality of a module is moved >> to the core or somewhere else, there will be a new valid object which on >> the long run replaces the old. > This is public API, and things generally can't be removed from the > public API. If you use "module-loopback" in the API, and then the > implementation gets moved to a library or the core, we'll have two > choices: either duplicate the same functionality under a new name, or > keep using only the "module-loopback" name. Both cases are undesirable, > when there is no underlying module-loopback instance involved. > >>>>> I now noticed that in your patch the message name and parameters are >>>>> not separate. I think it's good to be able to register separate >>>>> handlers for separate messages. Multiple modules might want to register >>>>> different message handlers for a single recipient object. For example, >>>>> the alsa modules could register alsa specific sink messages and an >>>>> equalizer module could register equalizer messages for the same sink. >> This is a good example for what I mean. You are saying "alsa specific >> sink messages" and "equalizer messages for the same sink". >> This shows for me, that the messages do not belong to the sink >> object itself, but to the underlying alsa backend or the equalizer. They >> just operate on the same sink. > When an alsa sink is created, the system will have only one sink, not > one "core sink" and one "alsa sink". However, if the alsa sink is not > able to add a new interface to the sink object that the core creates, > then the API will look like there are two separate objects that are > both called "sinks": > > /core/sinks/alsa_sink_1 > /alsa/sinks/alsa_sink_1 > > I would find the interface cleaner if there was only one sink object, > but there are also benefits to having only one interface per object, so > I don't have a strong opinion. > > You could avoid the ambiguity by using /core/sinks/alsa_sink_1/alsa for the alsa backend or for an equalizer /core/sinks/alsa_sink_1/equalizer, so that the alsa backend or an equalizer appear as objects below alsa_sink_1 even though they are created as independent entities. I'll send a new patch in the next days.
