Brock, > Group 1: > All of our code amounts to an API > The GUI, the CLI, and the backend all live in the same gate so it's > reasonable to check all changes made to all functions > The problem we've been having is essentially a social one which is best > solved through better testing, diligence in code reviews and discipline > when writing the code in the first place > By the time an adequate API is in place, it will duplicate the object > structure of the back-end anyway > The solution is to (as Tom said) improve exception handling, move UI > stuff, move logic into the back end, improve documentation
This position isn't tenable or realistic. We do have code in our gate, but currently, there's no way to tell what interfaces ought to be used. Many classes need refactoring. If a new team were to show up and look at the existing CLI and GUI code, I suspect they'd be utterly mistified about how to procedd writing a 3rd client that uses the "interfaces" that allegedly exist. The problem is partially social, but we've already tried social solutions. We still have duplicated code, unclear interface boundaries, and unintended breakage. We've tried Group 1's solution, and it wasn't adequate. > So how do we go forward? This is important because a) we told the GUI > team we'd have an API for them and if we want it being used by > november, this needs to move quickly b) I thought this was a high > priority item in terms making the code safe. You may have to go forward without consensus. You're the one doing the work, ultimately the decision is up to you. You're an advocate of Postion 2. I think you're correct. The more time you spend arguing with people who won't change their mind, the less time you have to write code. If they think they can do a better job than you can, let them code up an alternate solution. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
