Auto-refresh timeline

[IBBoard]

Some structural changes and timeouts to give us auto-updating timelines that poll for new messages every two minutes.

Also implements the "load older on scroll back" behaviour.

I'm not sure of the balance between "file per class" and "minor extension classes just go in the same file", so I can refactor if there's a preference.

[CodedOre]

There are some good things in here, but I need to request a few changes:

1. I think ExpandableCollection should be merged into Collection. The only collection that wouldn't use pull_old_posts would be Thread, so I would rather split this of Collection if neccessary.
2. Automatically pulling for updates should be done in the backend, with CollectionView only activating it.
3. Mastodon has an proper Streaming API, so we might want to use that for updates.

[CodedOre]

Mastodon has an proper Streaming API, so we might want to use that for updates.

I have to admit, I only just now looked at the docs, and it seems like we could only stream the HomeTimeline together with the notifications. So, this means the following:

• The auto-update property is likely to be exclusive to HomeTimeline. Should be fine though.
• For Mastodon we probably want a StreamingUtil, which takes the stream and updates the HomeTimeline and the notifications.

Since I would want to take a look at notifications, I would say I take care of updating HomeTimeline with the stream.

[IBBoard]

1. I think ExpandableCollection should be merged into Collection. The only collection that wouldn't use pull_old_posts would be Thread, so I would rather split this of Collection if neccessary.

Wouldn't that result in Thread re-implementing some of the collection behaviour? Or extending Collection and turning the automated fetching with null operations (which seems ugly).

2. Automatically pulling for updates should be done in the backend, with CollectionView only activating it.

I think I was trying to avoid having the backend set up unexpected requests. But I can probably rework it so that it doesn't make the regular requests by default and starts & stops the stream or polling.

3. Mastodon has an proper Streaming API, so we might want to use that for updates.

I hadn't thought to look for the streaming API! I can probably find a way to map that into the API so that we support both streaming and polling, in case we ever end up with a Twitter-like API without streaming.

[CodedOre]

Wouldn't that result in Thread re-implementing some of the collection behaviour? Or extending Collection and turning the automated fetching with null operations (which seems ugly).

Yes, splitting out Thread would probably mean that we re-implement stuff from Collection. However, I think it could make sense in the long term, as Thread is representing a different data structure than the other sub-classes of Collection. Collection is mainly for reverse-chronological timelines, while Thread is supposed to be representing a part of a tree-like conversation.

I think I was trying to avoid having the backend set up unexpected requests. But I can probably rework it so that it doesn't make the regular requests by default and starts & stops the stream or polling.

I think it would work to have an Boolean property like auto-update which the frontend can control to determine if updates should be pulled. Since the only things we probably want to pull automatically are home timeline and notification, I would say we place this in Session, from which the class implementing the Streaming API determines if it should run.

[CodedOre]

Just a heads-up, since it might affect this PR:
I intended to work on adding notifications today, but have noticed early on that the list of notification would essentially be another variation of Collection. So I'm currently experimenting with a overhaul of Collection, so it can be more flexible.

[IBBoard]

I'm looking in to this again after all of the changes on collections.

I may have found a problem with streaming and Vala:

The name continuous' does not exist in the context of Rest.ProxyCall' (rest-1.0)

And from the docs: "This method is not directly available to language bindings."

"not directly available" suggests it might be indirectly available. but I bet it isn't 😐

Maybe this is why Baedert moved the stream processing to C?

[IBBoard]

I saw Tooth mentioned when looking at other posts tagged #Vala. So I had a look at what they're doing.

It looks like they're going completely different, avoiding librest for the stream and going all the way to web sockets!

https://github.com/GeopJr/Tooth/blob/main/src/Services/Network/Streams.vala#L47

Not quite sure how it's doing the authentication, though.