Call for feedback: is the option to "Store no more than __ latest items" necessary?
Right now there are two ways of limiting retention of items. They can be set globally as well as separately for each feed:
- "Remove downloaded items after __ days"
- "Store no more than __ latest items"
If you were to think of how to limit the amount of stored entries, these are the two most obvious ways that come to mind. And that's exactly what happened - when I decided to implement this capability, I thought of these two methods and I carelessly added them both. Only recently have I realized that I didn't think it through and that ideally a single option should be enough.
It occurred to me that maybe the latter option isn't really needed. In what situation would you absolutely need to set a hard limit? I can imagine a few cases in which a hard limit may be slightly preferable to a time-based one, but they are too subtle to be convincing. I started to think that this option isn't important enough to justify its place in the UI.
However, I may be missing something, hence this topic. Can somebody point out a concrete use case in which the hard limit is needed and a time-based limit isn't appropriate and simply won't cut it?
Re: Call for feedback: is the option to "Store no more than __ l
If there was a bug in someone's feed generating software, it could generate a feed where their entire backlog of entries all appeared with today's date. This would cause Brief to download thousands of unwanted entries, which may be significant if they all contained pictures.
I have never seen such a bug like this happen, and I probably wouldn't miss this feature of Brief if it didn't exist (or if it was just an optional global setting), but I can imagine someone will one day try to export and import an RSS feed and the importer will fail to parse the date, and default to "today".
Keep up the good work on your excellent software.
Re: Call for feedback: is the option to "Store no more than __ l
I think the "store no more..." option is necessary. I use it and set it to 30.
Planet-type feeds generate a massive amount of posts per day which can easily flood you and generate a huge database file. Typically one is not interested in reading each and every post, but check the general mood and see where things are going with the community. You can't possibly read all posts in these cases.
On the other hand, personal feeds have 3 or 4 posts per month, and in those cases you want to keep them for at least a few weeks (I keep them for 30 days).
So yes, I think both options (post quantity and post age) are useful.
Re: Call for feedback: is the option to "Store no more than __ l
This doesn't explain why you'd need a hard limit here. It seems that a time limit would work just as well.
ancestor,
creator of Brief
Does it affect performance?
I subscribe to a lot of feeds (60-70) so I have set it to keep no more than 100 items in a feed to help prevent Brief from slowing down (it can be quite slow sometimes).
Not sure if it actually helps or not :)
I don't have a real need for the feed-specific settings myself.
Re: Does it affect performance?
All right, I guess it's a valid use case, even if an unfortunate one.
Right now I'm leaning towards keeping the hard limit as a global option and eliminating it from the Feed Properties window.
ancestor,
creator of Brief