incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <Alex.Hu...@citrix.com>
Subject RE: Arch Rework RFC: API refactoring updates
Date Sat, 08 Dec 2012 02:13:14 GMT
> 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

Mime
View raw message