On 02/03/2011 11:38 PM, Amos Jeffries wrote: > I think the moving the Coordinator to a registry subscription pattern is > what we need to do to fix the depdendency hell from SNMP support changes > yesterday. > > The problem stems around src/ipc/Coordinator.* containing > handle*Request() handle*Response() for particular components which are > it's users. The obvious ones are Snmp req/resp but the cachemgr ones > also hit from the inverse side. > > In the end the SNMP and MGR components should be higher level than IPC > and register a Subscription handler/call with it for runtime selection > instead of being hard coded at build time.
I agree that a subscription mechanism is a better design here and would reduce the number of inter-dependencies. Moreover, Coordinator and Strand classes do not really belong to ipc/. They have the same "level" as general "worker" code. We may not have a good place to put Coordinator right now, but the ipc library is not it. Should we move Coordinator into src/? Create a dedicated src/coord directory for it? Any better ideas? What about Strand (the thing that handles IPC messages for workers)? Create a src/worker directory/library for it?! I have not seen the actual problems yet (behind on squid-dev email), but it sounds like there are problems with building test cases and such, discovered, as always, after commit. The subscription API will not necessarily fix all of these for the reasons described by Christos, but it may ease the pain of figuring out the right magical combination of libraries in src/Makefile.am by reducing the number of dependencies. Moving Coordinator outside ipc will also help. If needed, I can help with the subscription design after SMP Rock Store is merged. HTH, Alex.
