Note: this could/should now use the Metadata API which will return the data ready to be displayed. This would be rather simple to build now! See example how PDF is created.

https://github.com/piwik/piwik/blob/master/plugins/PDFReports/API.php#L181

The interesting API is the metadata API, eg. http://demo.piwik.org/index.php?module=API&method=API.getProcessedReport&idSite=1&date=yesterday&period=day&apiModule=UserCountry&apiAction=getCountry&format=xml

Once we have HTML of all Widgets, we can easily have an option that "Email Reports" can contain HTML as well as PDF (a nice side effet of building this feature)

I'm going to implement /trac/ticket/2318 before working on this ticket.

Before starting development on this ticket I'd like to clarify a few points.

The new RSS functionality departs from the old one by using the Metadata API. Because some widgets may not publish metadata reports, the new RSS functionality can not be applied broadly to all Widget footers.

• Do we agree on dropping RSS as an API response format? If yes, we would do a rss redirect something like this when an API is called with format=rss.
• RSS icons in widget footers will now be conditionally displayed. Should we query API.getReportMetadata and compare with the plugin name and controller action ? There may be some renaming if they don't match the module and action names in the metadata report. Or is it ok to use (with reversed logic, ie. false by default)

$this->viewProperties['show_export_as_rss_feed'] = true;

• The new RSS functionality will be implemented as a new plugin and will only publish APIs (no new widgets, no new pages).

Good analysis.

I don't think we need a new plugin for this functionnality. Let's integrate it in core directly, or CoreHome, or elsehwere..?

OK to drop RSS as a datatable format. Don't bother about RSS redirect, we can simply state the API change in changelog.

Regarding the flag, $this->viewProperties['show_export_as_rss_feed'] sounds good. However, it must be set automatically, based on API.getReportMetadata indeed.

I think that controller.action and API.action all match, but it is well possible that some of them don't. Renaming should be OK (maybe it will remove the widgets from the dashboard, and/or from the PDF/HTML reports already setup, but maybe not). As long as things that 'had' the report before renaming, are not broken by the renaming, it is fine to rename -hope it makes sense hehe ;)

Also, see #1664 which has suggestion around proper RSS pubdates

Should I use the Zend framework RSS builder ? Or are we trying to lessen dependencies to this framework ?

If you can use the Zend_Feed module (already in trunk), please do. It's underutilized at the moment (e.g., ExampleFeedBurner).

I am currently building the API method which will generate the RSS stream.

For normal RSS usages, correct behavior/value for the $date parameter is 'previousX', ie. 1 RSS entry equals 1 complete period.

Should the API allow a less restrictive approach and let the API caller set values for $date ?

In this case, what is the expected behavior if $date equals '05/01/2011' ? Should the RSS stream contain only one (probably partial) report ?

What about date ranges? Should it behave like previousX ? Or should it output only one entry?

My opinion is not to allow $date parameter to be overridden and to fix it to previousX. X being hard coded or configured in global configs.

I would agree with your proposal: simple is better. RSS will be used to get updates in the feed reader, so no need to handle past dates (users can use other formats such as XML for past dates).

By default, maybe X can be quite high (50 entries?).

(In [4879]) fixes #2414 refs matomo-org/matomo-mobile-2#2350 refs #5571 - metadata support for previousN/lastN

(In [4900]) refs #2414 #2350 #151 - fix for bug introduced on json arrays and objects + adding first layer of unit tests

There have been good improvements made in #2714 and now, Column names are translated. Still not as pretty as Piwik report, but quite good for RSS as it is.

The implementation could reuse the HTML reports templates.

Also, the &format=html could use this "pretty table" view. Then, the RSS export would use the HTML renderer. This would add 2 new features at the same time (pretty RSS reports, and lightweight HTML embed reports).

Depends on #3031