Rss-bridge: Discussion: ICS Support

[captn3m0]

Creating this issue to discuss a possible idea: ICS Support.

ICS calendars are great, interoperable, and quite similar to RSS Feeds:

• They can be subscribed by clients
• The client decides how they look/behave
• Client polls the ICS URL to fetch any updates

The usecases are slightly different though. RSS targets "newsfeeds" primarily. This project is proof that it can be used for far more than just news feeds, but general updates of any kind. However, there are 2 major limitations:

1. RSS timestamps aren't really used by clients. This means for "event" like bridges (Like I was working on at #1394), you are left with filling the event datetime information inside HTML, which makes it unusable for most clients.
2. RSS doesn't support "future" publications. The spec leaves this to the client, which may decide to not show future posts. In general, news/RSS is about events that have happened, and ICS is about things that are going to. This distinction makes it hard for RSS to be used for event posts.

A couple of examples from the wild:

1. MuSpy supports subscribing to artists you like (via a very easy Last.FM integration) using both RSS and ICS. The ICS feed shows me "future releases" as well on the correct dates on my calendar, which is very important. We have similar bridges (Discogs, BandCamp), but none support Future releases.
2. Meetup supports both RSS and ICS feeds. The ICS feed is only for member notifications sadly, but if there were easier ways for me to subscribe to meetup via ICS, I'd use it over RSS.
3. CloudSploit sends out notifications about "future" changes to their API via a shared google calendar.

Since the project is called "RSS" bridge, I'm not entirely sure if adding ICS support within this is a good idea. I don't want to create a fork either, because that would fragment the bridges. Keeping it on the same project also has a few other advantages:

1. All bridges automatically start supporting ICS (might not be great, but usable automatically)
2. Any bridge can opt-out of ICS by setting a config option.
3. Any bridge that wants a special-opt-in can define a collectICSData (or similar) method to convert the data to be better suited to ICS format.

The ICS spec is at https://tools.ietf.org/html/rfc5545. It isn't exactly great, but this would only require a minor subset to be implemented.

[AntoineTurmel]

see also #421 ;)

[captn3m0]

I searched for ICS :man_facepalming: Thanks!

I think in the long run it is beneficial to have this as a feature to prevent bridge updates across multiple projects.

[em92]

I suggest to fork as separate project (I don't recommend using github's built-in fork, "Search" in code will not work in forked project). One of the reasons is this:

news/RSS is about events that have happened, and ICS is about things that are going to

In other words, RSS and ICS solve different tasks. Mixing them in one project that is associated with RSS will generate confusions.

I think in the long run it is beneficial to have this as a feature to prevent bridge updates across multiple projects.

I don't think so. Afaik, many existing bridges do not produce feed items associated with future events.

[LogMANOriginal]

RSS doesn't support "future" publications. The spec leaves this to the client, which may decide to not show future posts.

In my opinion future publications simply don't make sense in news feeds. It's as if someone says "here is the information you are looking for, but don't peek until two weeks from now". The specification should consider future timestamps as invalid. I suppose it's too late for that :frowning_face:

In general, news/RSS is about events that have happened, and ICS is about things that are going to. This distinction makes it hard for RSS to be used for event posts.

News feeds were originally designed as a way to inform subscribers about new content. It can certainly be used to inform users about new events that will happen in the future (like an announcement). The ability to add those events to a personal calendar, however, is something entirely different.

I agree with @em92. This should be a separate project. Of course, your bridge could point to such a service within the feeds produced by RSS-Bridge :wink:

[somini]

I think a POC can be done with a Format, like we currently have for Mrss, Atom, Html, it should be a pretty small amount of code.

IMHO, this whole project is pretty free-form (in a good way), so having a best-effort implementation doesn't really clash with everything else.

We have plenty of niche bridges already, having a niche format doesn't hurt. :grin:

[captn3m0]

I'll give it a shot and see if the change can be kept minimal. If it seems too large, I can split it off.

[em92]

Hi, @captn3m0 !
There is a https://github.com/RSS-Bridge/rss-bridge/pull/1711 that is better for ICS feeds rather than RSS feeds. Any progress in ICS bridge implementation?

[captn3m0]

Nopes, no progress yet.

[Danoloan10]

i'm taking a look into this, and it seems quite easy to do a RSS-bridge clone supporting ICS; the only files i have seen need modification are lib/FeedItem.php (to change the fields of an item) and a new format/ICSFormat.php. I will read the specification and see how it can be done.

having it integrated into RSS-bridge would require an abstraction of the FeedItem object, because the fields of a RSS item and an ICS item are very different. that seems a bit more complicated, but not that much.

[Danoloan10]

I have managed to get my fork of RSS-bridge working with an additional ICS format, over here.

The main changes made to the codebase were:

• Added lib/Event.php class - similar to lib/FeedItem.php
• Added lib/Calendar.php class, used to generate the ICS object
• Added formats/ICSFormat.php (duh)
• lib/BridgeAbstract.php:
  
  
  
  • Added $events attribute - an array of Event objects (similar to the items attribute)
  
  
  • Added getEvents()
  
  
• lib/FormatAbstract.php:
  
  
  
  • Added $events attribute - an array of Event objects (similar to the items attribute)
  
  
  • Added getEvents() and setEvents()
  
  
• actions/DisplayAction.php:
  
  
  
  • The same actions done to the $items array in the execute() function are done to an $events array, including capturing with BridgeAbstract::getEvents() and caching
  
  

The Event object has the following attributes (mandatory unless otherwise stated):

• $uid: UID of the event - same as RSS
• $stamp: Unix time of creation of the event (optional)
• $start: Unix time of start of the event
• $end: Unix time of the end of the event
• $summary: Title of the event
• $description: ... (optional)
• $location: ... (optional)
• $fill: this one is a boolean - if true, only the days of the $start and $end times will be taken into consideration (not hrs, mins or secs). This is to enable the creation of whole-day events. Defaults to false.

The bridge of #1711 has been modified to fit ICS and included as an example.

The only thing that does not convince me that much is that both ICS and RSS are active by default on all bridges. But well, this is a PoC more than anything else so yeah

Edit: I have deployed it in my personal web page at www.danoloan.es/rss/index.php, and is working nice and smooth.