> What's done and plans: > I've separated out api cmds as per admin, user pkg so that developers would > know what security level the apis (Cmd classes) are in. Next, I separated > them based on entity group (like all vpc, vm etc. related apis go together). > This was done only for developers, so they would know where to look for > them and contribute. This would also help us generate better automated > apidocs, the grouping and classification is done manually by hand. Right now > I've fixed the build and apidocs build as well.
There two additional benefits to breaking into different java packages (not jars). - It's easier for developers to look for the command related to their functionality. Because the java files start with action, it is difficult for developers to look for the commands among 300 commands lumped into the same package. With his change, developers can first look for the package and then their command. - Documentation tool can automatically put the commands down as related to each other according to the package. This allow someone when reading the documentation to find related commands and entities. Note that this causes no change in the over the wire semantics whatsoever. What the otw command is and how that is associated with the java class is defined in the commands.properties file and is unrelated to java packages. We are absolutely open to suggestions as to how commands should be grouped. Some are obvious (e.g. all commands related to loadbalancing is grouped under loadbalancing). Some are not. And we don't expect we'll get everything right on the first pass but we hope to get it started. --Alex
