Upgrade RSS behaviour to be more friendly

[elementh]

Currently the RSS implementation seems to only includes the opening paragraph, this is not very friendly to RSS readers, forcing the reader to open the website to read the rest of the post.

Please consider upgrading the RSS behaviour to include the full post, just as other blogs (such as the official dot net blog) do.

Also, if you would accept a PR with these changes, let me know, as I would be happy to contribute.

Thanks.

[linkdotnet]

Hey @elementh

The choice to not include the content was deliberate at the time. My concern was and still is, that with reasonable amount of blog posts, that endpoint has to send quite some heavy data.

My current endpoint (https://steven-giesel.com/feed.rss) already sends 200kb without any content.

So we might have the following options (correct me if you see more):

1. Pagination - which is only supported for a limited range of clients (or switch to ATOM)
2. Offer multiple RSS feeds.
3. Offer one feed with query parameters. Like (feed.rss?last=100)

The most promising would be the 3. option for me. Not sure how easy it is to configure for users, as they have to know the "magic" query parameter here. But all in all, I am welcoming, including the content.

I am absolutely fine if you file a PR once we know which direction we want to go.

[elementh]

Hi @linkdotnet

Thank you for your quick response and for being open to considering changes to the RSS behavior.

Option 3 sounds like the most promising approach. I agree that the parameter might be somewhat challenging to "discover," but perhaps we could document it in the README for this repository? Another possibility could be to modify the RSS button into a selector that offers two options: the current feed or an extended feed.

A final option would be to default to displaying the last X posts without involving query parameters. However, I must admit, I'm very interested in the idea of being able to retrieve all posts, regardless of how long ago they were written.

What do you think?

[linkdotnet]

Exactly - if we pursue number 3 we will have a sensible default of probably 50-100 blog posts. OR: Just allow everything and only send out X blog posts, if and only if the user is specifying the query parameter.

For me, query parameters are optional, and if they are not present, we have to define some sensible default.

From a UX perspective, I am open to how to solve that. Maybe we can learn how others (like substack/medium) do it.

[elementh]

I agree with you, query parameters should be optional and have sensible defaults in place.

Your blog is unique in offering all blog posts through the RSS feed. While I follow a few others that do the same, it’s not very common. For example, Substack typically sends longer excerpts, not the full content, and limits it to around 20 articles.

Ultimately, I think the defaults should be up to you, since it’s your blog. Personally, I’d lean toward having the last 50 full articles by default and allowing a query parameter for retrieving more.

As for UX, which isn’t my strong suit, I think the least intrusive option might be a dropdown menu or maybe a section in the "Archive" explaining how to access an extended RSS feed with full content... (maybe it can even be labelled and marketed as an "Archive RSS"?)

[linkdotnet]

I am tinkering with the thought of (as you mentioned) of offering always everything but only the last 20-50 will also share the whole content.

I do have to sleep a night over that.

[linkdotnet]

I believe I settled on one of your initial thoughts:

... I think the least intrusive option might be a dropdown menu ...

And I do agree with that. Mainly, I would like to keep the current status quo and backward compatibility. That said, the current button should do what he always did. But, as you mentioned, a dropdown (on hover) would be nice to have another option. The "full" version, that includes the content. And there is already a setting: BlogPostPerPage, which is used to set the page size.

We could use this (or *2) to determine how many "full content" blog posts we will send down the line.

What you're thinking of this? @elementh

If you want, it would be up for grabs. If you need any help, just let me know.

[elementh]

Let's recap to ensure we're aligned on the key points:

• UX/UI: Implement a dropdown on hover to maintain the current status quo and user experience.
• RSS Content Display: Use BlogPostPerPage (or multiply it by 2) as the default for determining the number of full-content posts displayed in the extended RSS

I have a few questions to clarify:

• Are we still planning to allow a query parameter for customization?
• As a "nice to have," should we consider adding a parameter (e.g., ExtendedRssNumberOfPosts) that could override the default behavior of using BlogPostPerPage (or *2)? This would make the two settings less tightly coupled and provide more flexibility.

This is shaping up really well!

I'm definitely interested in taking this on, and I'll gladly take you up on your offer for help if needed.

[linkdotnet]

UX/UI: Implement a dropdown on hover to maintain the current status quo and user experience. Exactly. Basically, offering two options. The current one, if you just click on the button (like today) or (on hover) extend a dropdown with the fullversion-link.

Are we still planning to allow a query parameter for customization?

Maybe we can join this pat with your "nice to have" part. Allowing an optional parameter which is (for now) describes in the README.md where you can optionally pass a value.

If we do this, I'd feel safer adding rate limiting for those controller calls as they might take a big toll on the database.

[elementh]

Good idea on implementing rate limiting—that makes sense. However, I'm not quite following your point about the join. Could you elaborate on that part a bit more?

[linkdotnet]

Ah sorry.

Are we still planning to allow a query parameter for customization?

Basically you can join this with:

As a "nice to have," should we consider adding a parameter (e.g., ExtendedRssNumberOfPosts) that could override the default behavior

Or better: The query parameter would be how to achieve your "nice to have". So we can have a query parameter ?numberOfBlogPosts=100 which would extend the default amount (which might be BlogPostPerPage * 2)

[elementh]

It makes sense! I'm happy to take on this task. Once I have something ready for review, I'll start a draft pull request so we can stay aligned throughout the process.

[linkdotnet]

Sounds amazing! Thanks for taking the lead on this one!

[linkdotnet]

Reopened for Rate limiting. CC @elementh

[linkdotnet]

Closed by e94c5a3da1a6e7fa47695962792c1a6ee6bd8d25

CC @elementh

[elementh]

Nice work! Sorry I didn't close it myself, got distracted with some stuff :sweat_smile:

[linkdotnet]

Nono it was all good. I added the rate-limiting (by IP) in the given commit. You did everything right ;)