search

RSS-Bridge / rss-bridge

The RSS feed for websites missing it
https://rss-bridge.org/bridge01/
The Unlicense
7.38k stars 1.04k forks source link

Discussion: ICS Support #1351

Open captn3m0 opened 5 years ago

captn3m0 commented 5 years ago

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

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

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 commented 5 years ago

see also #421 ;)

captn3m0 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

Nopes, no progress yet.

Danoloan10 commented 4 years ago

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 commented 4 years ago

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:

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

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 2 years ago

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:

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 commented 2 years ago

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:

esquema rss

dvikan commented 2 years ago

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 commented 2 years ago

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.