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 https://danoloan.es/rss/index.php, and is working nice and smooth.

[mateuszjablonski]

@Danoloan10 this looks great! I am wondering - is it necessary to have separate $events , getEvents(), setEvents()? Can't we just use existing $items, getItems() and setItems() and then create some kind of mechanism to be able to determine if an object is indeed an Event? Maybe even abstracting FeedItem to some more generic class?

[Danoloan10]

@Danoloan10 this looks great! I am wondering - is it necessary to have separate $events , getEvents(), setEvents()? Can't we just use existing $items, getItems() and setItems() and then create some kind of mechanism to be able to determine if an object is indeed an Event? Maybe even abstracting FeedItem to some more generic class?

i thought of events and feed items as elements with different enough characteristics to consider them separately. think that feed items can be entire blog entries with a publication date, while events have location, title, comments, etc. and not a pub date but a due date. these differences are slight but fundamental, that's why I didn't merge them. However abstracting a superclass may be useful for the future, yes.

[simon816]

In the spirit of "giving it a go", I've created a project, iCal-Bridge: https://github.com/simon816/ical-bridge

I agree with previous comments that such a project should be separate to RSS-Bridge, at least in the first instance.

It is largely copied from RSS-Bridge, there are a few reasons for this:

• Both projects share a lot of common functionality (html scraping, caching, frontend, configuration)
• Many of the required features were readily available in RSS-Bridge (this project took a matter of days, not weeks)
• Opportunities for a shared library of sorts, a generic "web scraper to $x format" could be a common framework
• Possible inclusion back into RSS-Bridge

While RSS and iCalendar represent fundamentally different information and therefore you can't substitute one for the other, I think there's an interesting opportunity for an "ICS to RSS" bridge, where changes to a calendar are published to an RSS feed.

Anyway, I hope to use this for my personal needs, and may add bridges as and when the need arises. I'll accept contributions from others too, should anyone else find it useful (do note that the license and therefore any contributions will be under GPL-3.0).

[Danoloan10]

I've pondered the option of abstracting events & news... but they are just too different, so much that they may use different UIs to be represented in the Bridge view. Something along the lines of this draft:

[dvikan]

The html (HtmlFormat) display of a feed is mostly for making sure it fetches data okay and for debugging/developing. What is important is how it's rendered in feed readers. E.g. the feed item publication day and how to embed the event date. Maybe just embed the event data as text. If you are talking about the actual feed item html and how to render the event as a feed item, im with you.

edit: i realise i've misunderstood the op. They are talking about ICS as an output format.

[Danoloan10]

I see your point, and I think I misunderstood the purpose of HtmlFormat. What bugs me most, and I think @LogMANOriginal too, is that news items are just too different from events as to put them together or represented using the same UI. This would be a solution to that. But the calendar may be overkill for a first approach, we could do something like HtmlFormat first.