On Wed, 2013-06-19 at 19:50 +0200, David Henningsson wrote: > On 06/19/2013 05:40 PM, Tanu Kaskinen wrote: > > pa_port_node takes care of things that are common to all port nodes. > > The port device class is used in the node name for some extra > > user-friendliness. The goal is to avoid the long and cryptic names > > that are currently generated for sinks, sources and cards. > > I'm not following. Why do we need extra pa_port_node and pa_sink_node > objects? Why don't we just have a pa_node pointer (or even embedded > struct, if that makes sense) in pa_device_port / pa_sink instead? pa_node will probably have some callbacks, at least for activating the node. I expect that e.g. pa_port_node would have a common implementation for activating ports. There may or may not be need for further specializing the activation code by adding an activation callback also to pa_port_node. This is largely speculation, however, because this hasn't been fully designed yet. If you think pa_port_node is bad, we could try going without it until we actually need it. > If every sink, source and port have exactly one node, that seems to be > the logical object model. Or can sinks, sources and ports have more than > one node attached to them? I don't think it's likely that we would some day need one port or sink to have multiple nodes - we certainly don't need it today. It's entirely possible that a port or a sink could have zero nodes, however (or at least it's possible for sinks - e.g. bluetooth sinks don't have nodes, and neither do alsa sinks if ports are present). -- Tanu
