[Dev] Script/Report plug-in convergence

[Brett Wooldridge]

Leo,

After looking at the existing infrastructure I think we are closer to what you suggested than we thought.  Yes, there is a different Job (ReportJob), but I don't think that's a big deal - the CommandSetJob could have been a ScriptToolJob too but it's not.  Other than that difference (the name of job type put into the JobData), there is no difference between a Report plugin and a Script plugin from an API point of view.  I have added no new public APIs in support of Reports, all existing APIs are sufficient.

However, just as we've added to the kinds of properties available to a tool in the past, there are new properties for reports that have implications for the UI - but should still be applicable to both tools and reports if you choose to make them so.

These will come across the wire to the client in the property text stored inside the PluginDescriptor:

output.format
  This can be csv, html, <whatever>, or birt.  If it's 'birt' we should give them a choice of display types.  If not specified the client should assume CSV for backward compatibility.

mode.supported
  This property was already there, and we allowed values of "single"/"multi", and it indicates how devices are selectable for the plugin.  But there is a new one we need to support, "none".  This means that the user CANNOT select devices and there should be no device selection capability.  Maybe the tab isn't even visible, I dunno.  We need this because some reports always run against the whole inventory, or don't care about devices at all.

These are new properties that can be specified in either a script plugin job or report plugin job:

email.format     - if sending mail this is required email.to         - if sending mail this is required.  semi-colon separated list of email addresses. email.cc         - optional.  semi-colon separated list of email addresses. email.link       - either this must be true, the next attribute must be true, or both can be true email.attachment - either this must be true, the previous attribute must be true, or both can be true
However, if we expose these for Script tools right now, realize that you are creating some work for me as we can't currently email tool output.  Note that the "email.format" in the case of reports can be any supported birt format (pdf, html, xls, etc.), but if the "output.format" is not 'birt' then "email.format" should be whatever format "output.format" specifies.

In order to support a "unified" front (i.e. client doing very little work to distinguish between Script Plugins and Reports), I am going to kill the PluginProvider.getExecutionDetails() method.  The only way to get output of any kind from either a tool or a report is via a return trip to the viewer servlet.  This is because returning a +50MB PDF report file or HTML output from a script via getExecutionDetails() cannot scale.    The servlet as it stands streams data to the client and will avoid this issue.  Killing PluginProvider.getExecutionDetails() will obviously have an impact on the UI display code.

Lastly, the new script/report job editor should support the SimpleSearchResolutionScheme.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ziptie.org/pipermail/dev/attachments/20080324/623c24a5/attachment.html