Peeringdb: Have an RSS-feed (like) functionality to be notified about new objects created in PeeringDB

[koalafil]

This is a request from Walt Wollny and based on his feedback.

The idea is to have an RSS feed or some other similar functionality which periodically will send updates to subscribers showing new objects created in the PeeringDB since the last update. It could be weekly I presume.
[Of course POCs should be shown in the feed in accordance to their visibility settings...]

Thoughts?

[netravnen]

Commentary Input

The current JSON API can be used as data-source for this functionality.

• Fetch the N most recent entries based upon creation time (descending order, newest to oldest), and
• Format data output in RSS compliant output.

_Example using bash, output is json format_

Fetch 5 latest created facilities in PeeringDB: NUM_COUNT=$(curl -X GET -snGL https://www.peeringdb.com/api/fac | jq '.data | length') ; NUM_SKIP=$[${NUM_COUNT} - 5] ; curl -X GET -snGL https://www.peeringdb.com/api/fac?skip=${NUM_SKIP} | jq (since any of the current optional URL parameters for the API does not support functionality to "_fetch N latest created entries_", but only "_fetch N latest updated entries_".

_Basic PHP examples_

• 50 most recently created facilities | _source code: fac.php_
• 50 most recently created networks | _source code: net.php_

Reworking the supported optional URL parameters for the API could allow for the API to be a perfect fit as a data backend for this user request.

[koalafil]

@ccaputo @job do you have input as well, from OPS committee perspective ?

[ccaputo]

I don't see this as an Ops issue at this point, but rather something for PC to consider having developed.

Limiting PoC visibility based on user permissions implies to me this needs to be run by the user. Ie., Walt runs a regular script which uses the existing API with his login. Or ProductComm specs a per-user (or identical for all logged in users) RSS feature of some sort.

[grizz]

Honestly, I don't see much of a use case for this, like @netravnen said, it's accomplishable via the API.

I also don't see a reason not to do it... :) @peeringdb/pc votes?

[shane-kerr]

I guess that I'm in favor of updating the API to allow an RSS (or similar) service to be provided is reasonable. We can actually decide whether to build an RSS service as a separate issue, I think.

While running an RSS feed is not a big or complicated service, it does mean updating documentation, updating our monitoring, and making sure that whoever handles operations is willing to handle the additional work.

[ccaputo]

Every new feature increases paid & volunteer work load in a multitude of ways. Thus I must ask, is there demand for this beyond that expressed by one person?

[grizz]

I guess that I'm in favor of updating the API to allow an RSS (or similar) service to be provided is reasonable. We can actually decide whether to build an RSS service as a separate issue, I think.

This is already easily accomplishable, every list call takes since to limit to the objects updated since that timestamp.