Re: [birt-dev] Better charting (was better graphics)

[Henning von Bargen <H.vonBargen@xxxxxxx>]

Yair Lenga wrote:

> I do not think that BIRT need “BIRT charting” for client side charting (like the server side). There are multiple amazing packages out there, with unique functions, use cases, etc.
> Instead, I believe we should look for a way to export all the chart information (series, data, attributes, properties, including user defined  attributes) into json object, 
> and invoke JavaScript callbacks, passing the data. Different plugins can then be developed to connect to different packages.
> I would even go to the point that for minimal implementation, there is no need for HTML preview - in the editor. The existing server side can initially be used.
> Once we have exporter, we can see what connectors will be available, and pick one (or more …) that can be bundled.

Feel free to develop and contribute something like that, as a plugin.
You can use the existing chart plugin as a template.

I SERIOUSLY doubt the BIRT open source community can maintain it
We need to stay focused on the core functionality of BIRT, which is to convert data into documents.
The situation would be different if some company is willing to pay 2-3 full-time developers for several months or years.

Anyway, if you can develop a chart plugin that gets the chart data from a JSON service of the BIRT server on demand in a secure way and renders on the client, that would be great.

Step one would be to specify such a JSON service in a generic way.
Parameters which I think would be needed generically: 
- An ID for the currently shown report (I don't know, but I think this must already exist anyway for those reports with pagination in the browser).
- An instance ID for the chart in question.
- A generic JSON structure to specify which data exactly the client requests.

Step two, then, is to develop the backend side:
- Create the JSON service as part of the server.
- Create an alternative chart plugin which does not render charts, but instead can interact with and provide data for the JSON service.

Step three is to develop the client side:
- Create a Javascript/CSS/HTML client library which interacts with the user and the JSON service and renders the chart as interactive HTML/Canvas/Image/SVG.
- Integrate this Javascript/CSS/HTML into the HTML created by the server.

Of course, all this interactivity only works for HTML reports.

For all other output formats (e.g., PDF), a solution is needed which runs on the server and creates static output as an Image or SVG.
Now this part is *really* tricky because this means you have to simulate a modern browser on the server side!

Developing a *dashboard* solution is something completely different, though.
Just to mention some points which users would expect and which you must think about:
 - Access control
 - An editor to create your own dashboards
 - High performance
 - Drill-down
 - Zoom in and out

Take HomeAssistant with its Lovelace UI as an example.

To reach these goals, it is not only necessary to develop software for all this - the data access API and the data structures have to be optimized for this.
 - For example, for efficient zooming in and out of time-based data with large datasets, you need to have data structures which allow this, e.g., not only the raw individual values must be stored, but also statistics per hour/day/week/month.
 - And of course, you need some kind of URL structure.
 - In many cases computing the statistics you want to show in the dashboards may be too slow to do it on-demand, so you'll have to pre-generate and cache them.

As much as I would love to see interactive charts in BIRT or even dashboards, I don't think we'll find volunteers to develop and maintain it.


Henning