Design goals:
- Client-side imaging (reduces network load in cases of multiple images and fewer server-side dependencies)
- Allow multiple charts on a single wiki page
- Must work without any configuration
- Jinja2 templating - ready for Trac 1.4
- No Flash
- Should not expose plotly's internal data format but for very special use cases
- Long-term stability:
- do not rely on eg. Google chart API not changing
- possiblity to maintain support for older chart libraries when upgrading to newer libraries
- do not assume that the open internet is accessible
... and maybe even: Allow the older charting plugins to be retired.
Request for further ideas:
I expect to invest some more time in the plugin, so good ideas and suggestions for prioritisation are most welcome.
So far, i have these ideas on my list:
- axis names directly derived from the query
- 2+ data series in the same plot
- configurable standard width/height/colour
- expansion of $TICKET in query text
- better query error reporting
- also use trac's ticket query language
- more plot types. Scatter charts come first to mind
- seek inspiration from MermaidPlugin's trick to avoid the id parameter
- (speculative!) interaction with other plugins. For instance, imagine that TimingAndEstimationPlugin's burndown function could act as a data provider for the present macro - that would on one hand give a nice separation of concern and on the other hand result in a more uniform graphical expression.
Finally, a very valuable contribution would be users' "interesting" (ie. non-trivial) SQL queries - adapted for the most common databases. A single wiki page collecting these would be valuable to many rather than the current scatter.
All the best
Theodor