I'm looking further into creating a session policy plug-in and found some issues that left me wondering if they were design intent or problems, any feedback would be appreciated.
The code seems to load the plug-in and during the session policy plug-in init it registers by calling connman_session_policy_register. The routine then stores the policy in a list based on the priority, then calls probe_policy. probe_policy then cycles through all sessions and assigns this session policy to any session without a policy reference. I have a couple concerns: 1. This occurs only at startup--unless these session policies can register themselves outside of startup. Therefore, there will never be any sessions. Therefore the code is a NOP, and is not called anywhere else. 2. If registration could happen later the second plug-in would never get assigned. Am I missing something here? The other issue is that there never seems to be a probe-like callback even when a session is created. The session is assigned the highest priority session policy no matter what. Typically systems I've used would probe all plug-ins in priority order and stop if the plug-in returns that it handled the probe. This would allow the plug-in to be specialized for more targeted use and allow for more than one supported plug-in. Currently the highest priority wins. My questions/issues are: 1. Was the session code ever meant to handle more than one plug-in? 2. Is a probe-like API useful in this situation? This would allow one or more policy plug-in to operate for a single session. This would, for example, open the plug-ins up to do special filtering based on specific gid's etc. If these seem like problems I might have time to address the problems. I just want to make sure of the design intent before spending too much time on solutions that are not in line with the connman design and direction. Tysen _______________________________________________ connman mailing list [email protected] https://lists.connman.net/mailman/listinfo/connman
