First, I like the idea of consolidating logic. I could see also implementing this as just an abstract base class that handles this common logic. I'm not sure which approach I prefer. Exactly what is the problem that you are trying to solve? Without more details, I'd lean towards implementing this logic in an abstract base class that all NetworkGurus can choose to extend.
Darren On Tue, Oct 29, 2013 at 9:42 AM, Hugo Trippaers <h...@trippaers.nl> wrote: > Hey guys, > > This is something i had on my wish list for some time. The current way > network gurus are handled is that each guru is asked to design a network and > will decide by itself to either do it or don’t. Most gurus have sane checks > on which types of networks it can handle, but we have seen issues there in > the past. > > With these changes the network orchestrator will check the capabilities of a > guru and based on that ask one or more gurus to design the network. With this > the power is where is should new, the network orchestrator. > > This also means that new networking plugins with gurus will have an easier > integration, just list the capabilities. It will also save some database > calls (once i clean out all canHandle functions) as gurus will have to lookup > less to decide if they should to their job. > > What do you guys think? > > Current branch is tested with devcloud in a manual test, so there is more > work to do there. I wanted to get some opinions while performing more tests. > > Cheers, > > Hugo
