All data is already available though RSS feed.
The problem is that these feeds provide the "plain data" and don't have CSS, nice colors, etc.
We can export the HTML from widgets output for each day or website requested, and put this html in the rss feed.
The reports could be made available through a RSS link below each widget. The feature could also be made visible in the "Widgets" page, just like users can now export widgets in iframe.
Note: some widgets would disable the automatic RSS conversion as it is not applicable, eg. the Live! widget that shows the latest visits on the website.
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.
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.
$this->viewProperties['show_export_as_rss_feed'] = true;
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?).
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