add ability to preconfigure an agent by sending down a tweaked version of an agent-configuration.xml file based off of user input. affinity group setting should be prominent, if possible.

user control - is it possible to chown the agent distribution after it is layed down remotely and then starting up the agent as that other user (this is to account for plugins that work best when the agent is started as the root user because of sigar issues with privileges to the native file system). do we need to support passing sudo credentials here as part of escalating privileges to perform any of these options the first time or on subsequent times?

support private key authentication, rather than password auth. This would enable us to be able to remotely install agents on clouds such as EC2 which require key auth.

if the default port is 22, why not pre-fill the input text box to make that explicit? (mazz: yeah, stupid me - its probably just a simply matter of adding "testField.setDefaultValue("22")" to the code.)

as a simplified form of administration, perhaps the user can mark that he wants to automatically ack the first inventory report from this newly deployed agent, which will simplify the workflow of having to deploy an agent, wait for it to finish deployment, and then go to the auto discovery queue to import resources (obviously if users want fine-grained control over what's imported, they would use this option)

instead of requiring the user to click "find agent" let's listen for the onkeypress event and automagically send a request to the remote box to see if an agent is installed in the path at the time the event was fired (this can be improved by installing a delay, where we wait for ~1sec of "quite time" [the user hasn't pressed any keys] before we fire off the check request to the remote box, which should prevent many checks as the user naturally types a full path out). we should then present a message ONLY when the user already has an agent installed in that directory. also, the install button should be disabled if such an already-installed failured occurs. (mazz: have to be careful here - the code does a directory recursion check via 'find' - so if you click "/" and pause for that quite time, we'll invoke "find / -name rhq-agent -print" which essentially checks the entire file system recursively, a potentially very expensive proposition - this could be expensive for any arbitrary directory name since we don't know the customer's file system layout - for example "/home/users/" might be the NFS location of all N thousands of users in the company and thus would be expensive to scan recursively all their locations)

are you checking to make sure that every parent directory of the specified agent install path is also NOT an agent installation directory? i.e., don't allow accidental installation of an agent as a sub-directory of a current agent (mazz: as noted above, we do a "find <dir> -name "rhq-agent"" so we a looking for the directory that the RHQ Agent uses when installing, auto-installing, updating. This should always find the one directory.)

support ajax-push semantics for the agent status. in other words, instead of users having to click the "update status" button, automatically push an update out to the page to notify the user of the latest status. an alternate solution would be to poll for updates every ~1sec until you realize you reach some sort of termination state, and then stop the polling.

network discovery? reachable boxes? perhaps auto-filling the hostname/ip fields, or presenting the discovery results as a drop-down list?

do we want to support protocols other than ssh?

will a list of already-installed-agents appear as children nodes until the remote agent install? or will there be a separate page to list them?

ability to push agents to multiple boxes at a same time (perhaps using IP masks, or list of IPs, or list of hostnames, etc)

support start/stop agent en masse