On Thu, 2013-10-31 at 10:47 +0000, Colin Guthrie wrote: > 'Twas brillig, and Tanu Kaskinen at 28/10/13 19:55 did gyre and gimble: > > I got the criticism about routing groups - if there are other concepts > > that you find questionable, please let me know. > > I think this is more just a "general worry". There are a lot of new core > concepts being introduced to achieve the end result and from the queries > and questions asked, I got the impression that the people with PA > background present were somewhat nervous about this, but perhaps I > picked up and generalised things too much? > > At the moment, the routing is very simple. Too simple (obviously!) but > at least it keeps it manageable and understandable right now. I guess my > main concern is that it will turn even very simple routing > configurations into a very complex beast. In the proposed system with routing groups, writing a new policy module would require the following: * defining the prioritization of routees * assigning each routee to a routing group * defining the rules of accepting routing targets to routing groups * prioritizing the routing targets within routing groups Fulfilling those tasks shouldn't be very complicated. However, my first attempt at implementing the fallback policy (routing everything to the default sink/source) turned out to be very complicated due to the mismatch between the sink and node concepts. Everything else was simple, but prioritizing the routing targets was hard. I have an idea for a different approach for the fallback policy implementation, which I hope will fit this model better. So, simple policies *should* be reasonably simple to implement, but there is a prior example that justifies the concern that this isn't always the case. The routing groups don't need to be in the core - the implicit routing algorithm (which is the thing that interacts with the routing groups) could easily be implemented in modules instead. I don't think this will make the system any simpler, though. The old routing model is "hey, a new stream appeared, what's the best sink for it?". The new model is that whenever something happens, the routing system has to answer the question "given all nodes in the system, what connections should exist between them?" The routing groups are a tool for answering that question, and I don't see much room in simplifying it (ideas are welcome, of course). > I asked during the meeting about if "connection" core concept was > needed. This was justified that it would be needed to do things like > loading loopback modules, combine modules or remap modules to join > things up as needed. This is a reasonable justification, but after some > reflection I cannot see how this can be a core concept as it has to have > implicit knowledge of the modules. If core is loading specific modules, > then those modules are not really modules any more as they are needed by > the core. Indeed, the core should never load any modules except when requested by some external entity. The proposed solution to this problem is to move the loopback, combine sink and null sink implementations to the core so that they can be used without loading any modules. The connection concept originated when discussing the client API with David. He thought that the implicit and explicit flags should really be an attribute of the connection between two nodes, instead of storing that information in the nodes. I agreed, and later we (me and Janos) realized that connection objects will be very useful at the server side too. -- Tanu
