Closed jaesivsm closed 8 years ago
I can update the crawler which is using asyncio. Not a problem. In fact it was a choice not to update the content of articles. But today I agree with you.
For the notification in the UI, the first thing to do is to mark again the article as unread. Maybe also add a Boolean (for example "is_updated") in the Article model, that will be used if the user opted in (or always...). But, I don't think that it is necessary to highlight the changes (kind of diff).
For the notification in the UI, the first thing to do is to mark again the article as unread. It may be interesting to suggest that the article has been updated and isn't new in the UI and not just "unread" it. Also, it may not be useful to unread a message which neither the content or the title has been updated. Even so, do I want to re-read an article just because the title has changed ? I'm not sure.
All of that could be customizable of course but I don't think it's the way to go. So here are the specs as I see them :
That the fairest I could come up with.
I think we need an option in order to disable this.
After only one day of use, I realize that a non-negligible number of articles are regularly updated. Generally articles from news feeds, but not only. Or for example just now, this article: https://www.laquadrature.net/en/Net-Neutrality-Major-Setback-for-Internet This is annoying.
Or maybe it is just badly implemented... But some feeds do not have this problem.
I'll try to look more precisely where is the problem (encoding problem, a variable part in a feed with JavaScript?, etc.).
I'll also test if the entry has been updated (https://pythonhosted.org/feedparser/reference-entry-updated.html).
crawler should be able to edit an article that has been updated, a notification in the ui should also be made available if the user opted in or did not opt out (tbd)