[Forum+RSS] RSS feed verkeerd gesorteerd?

[Tassadar32]

Ben sinds een paar maanden geleden gebruik gaan maken van google reader. Deze kijkt echter niet naar de tijden van items in een RSS feed en gaat er blindelings vanuit dat de nieuwste items bovenaan staan (wat volgens mij ook het meest voorkomt bij RSS feeds). Dit zorgt ervoor dat feeds van een topic in google reader niet werken. Erg jammer!

[crisp]

Feitelijk zijn de RSS feeds alternatieve weergaven van de gewone web-view en volgen dus ook de volgorde van die view. Voor topics worden de berichten oud naar nieuw weergegeven (tenzij anders aangegeven in je voorkeuren), dus die volgorde wordt ook meegenomen in de RSS.

Ik kan me voorstellen dat dat in een reader inderdaad onhandig is. Ik zou daar een andere sortering kunnen forceren specifiek voor de RSS feeds, maar het is dan niet meer omkeerbaar (overruled de gewone pref volledig).

[Wiethoofd]

Het viel mij laatst op bij de http://gathering.tweakers...nd/poster/226934/topics/1 feed (let op de /1) waar dus wordt gesorteerd op waar ik het laatst gereageerd heb, deze wordt in de 'reader' (in dit geval m'n custom rss-feed in m'n gallery) compleet genegeerd qua volgorde en de /1 wordt niet meegenomen.

crisp schreef op zondag 28 maart 2010 @ 22:48:
Ik kan me voorstellen dat dat in een reader inderdaad onhandig is. Ik zou daar een andere sortering kunnen forceren specifiek voor de RSS feeds, maar het is dan niet meer omkeerbaar (overruled de gewone pref volledig).

Is een aparte instelling/pref in de voorkeuren beschikbaar maken voor de RSS-feed volgorde niet user friendlier?

[crisp]

Wiethoofd schreef op zondag 28 maart 2010 @ 23:30:
Het viel mij laatst op bij de http://gathering.tweakers...nd/poster/226934/topics/1 feed (let op de /1) waar dus wordt gesorteerd op waar ik het laatst gereageerd heb, deze wordt in de 'reader' (in dit geval m'n custom rss-feed in m'n gallery) compleet genegeerd qua volgorde en de /1 wordt niet meegenomen.

Dat ligt niet aan de feed, maar aan het feit dat onze RSS aggregator wel sorteert op <pubDate> wat in dit geval altijd de lastmessage-timestamp is ongeacht de 'sort-by-reply'-switch.

[...]
Is een aparte instelling/pref in de voorkeuren beschikbaar maken voor de RSS-feed volgorde niet user friendlier?

Ik ben geen voorstander van overal maar een pref voor aanmaken. Als een 'omgekeerde' volgorde voor RSS van de list_messages feed logischer is* en er geen echte use-cases zijn voor de 'gewone' volgorde dan is een pref ook overbodig. Bedenk daarbij ook dat prefs voor RSS alleen toegepast kunnen worden als je de feed-id meegeeft.

* je krijgt dan uiteindelijk ook 1 feed-url voor een bepaald topic die zich verder ook niets van pageing aantrekt maar altijd de laatste x replies uit dat topic bevat.

[ Voor 7% gewijzigd door crisp op 29-03-2010 00:09 ]

[Wiethoofd]

Standaard omgekeerd is inderdaad voor RSS-feeds het meest logisch en dan is de pref idd overbodig.

Ik zal m'n gallery rss-feed eens neerzetten met de feed-id, al zou dat volgens mij in dit geval niets uit mogen maken., maar jammer dat sorteren op <pubDate> de sort-by-reply-switch overrulled

[moto-moi]

crisp schreef op maandag 29 maart 2010 @ 00:04:
Dat ligt niet aan de feed, maar aan het feit dat onze RSS aggregator wel sorteert op <pubDate> wat in dit geval altijd de lastmessage-timestamp is ongeacht de 'sort-by-reply'-switch.

Hoort een feedreader niet zelf de volgorde te bepalen aan de hand van de pubDate

[crisp]

Wiethoofd schreef op maandag 29 maart 2010 @ 00:17:
Standaard omgekeerd is inderdaad voor RSS-feeds het meest logisch en dan is de pref idd overbodig.

Ik zal m'n gallery rss-feed eens neerzetten met de feed-id, al zou dat volgens mij in dit geval niets uit mogen maken., maar jammer dat sorteren op <pubDate> de sort-by-reply-switch overrulled

feed-id gaat daar inderdaad niet uitmaken. Ik zou voor je gallerij die feed-id er ook niet bijzetten omdat je dan niet-publiekelijk toegankelijke topics terugkrijgt in je feed die dan vervolgens voor iedereen te zien zijn (maar niet altijd benaderbaar)...

vwb de sortering: datum-sortering is toch ook het meest logisch voor een feed-aggregator? Je zou hooguit kunnen stellen dat bij de 'sort-by-reply' switch de <pubDate> de datum van jouw laatste reply moet bevatten, maar dat is imo discutabel en niet iets wat ik hier graag in ga hacken (de veld-mapping is redelijk star).

[Wiethoofd]

crisp schreef op maandag 29 maart 2010 @ 00:25:
feed-id gaat daar inderdaad niet uitmaken. Ik zou voor je gallerij die feed-id er ook niet bijzetten omdat je dan niet-publiekelijk toegankelijke topics terugkrijgt in je feed die dan vervolgens voor iedereen te zien zijn (maar niet altijd benaderbaar)...

dé reden waarom ik de feed-id in eerste instantie weg heb gelaten.

vwb de sortering: datum-sortering is toch ook het meest logisch voor een feed-aggregator? Je zou hooguit kunnen stellen dat bij de 'sort-by-reply' switch de <pubDate> de datum van jouw laatste reply moet bevatten, maar dat is imo discutabel en niet iets wat ik hier graag in ga hacken (de veld-mapping is redelijk star).

Als ik puur de rss-feed bekijk - zonder op de pubDate af te gaan - zou de reader (zoals het voorbeeld van de TS) puur op volgorde waarop de items in de feed staan alles moeten weergeven. Laat je de pubDate de volgorde bepalen dan is idd de volgorde van plaatsing-sortering weg.

[crisp]

Wiethoofd schreef op maandag 29 maart 2010 @ 00:31:
[...]

dé reden waarom ik de feed-id in eerste instantie weg heb gelaten.

correct, die moet je ook weglaten als je feeds publiekelijk gaat publiceren.

[...]

Als ik puur de rss-feed bekijk - zonder op de pubDate af te gaan - zou de reader (zoals het voorbeeld van de TS) puur op volgorde waarop de items in de feed staan alles moeten weergeven. Laat je de pubDate de volgorde bepalen dan is idd de volgorde van plaatsing-sortering weg.

Ja, maar je hebt hier te maken met onze aggregator en daarvoor maken wij de keuze. Het feit dat de React-feed een pubDate bevat maakt dat we die ook gebruiken voor de sortering (pubDate is immers optioneel, als die er niet in zou staan dan gebruiken we de volgorde van de feed zelf).

In feite is pubDate vullen met last-message timestamp feitelijk ook niet correct (het zou het tijdstip van topicplaatsing moeten zijn), maar RSS is wat dat betreft gewoon een nogal ondoordacht (cq tè simpel opgezet) formaat...

[Wiethoofd]

crisp schreef op maandag 29 maart 2010 @ 00:45:
Ja, maar je hebt hier te maken met onze aggregator en daarvoor maken wij de keuze. Het feit dat de React-feed een pubDate bevat maakt dat we die ook gebruiken voor de sortering (pubDate is immers optioneel, als die er niet in zou staan dan gebruiken we de volgorde van de feed zelf).

Zou in het geval van de 'sort-by-reply'-switch de pubDate dan niet 'gewoon' leeggelaten moeten/kunnen worden om zo niet in de knoop te komen met de gemiddelde rss-readers?

[crisp]

Wiethoofd schreef op maandag 29 maart 2010 @ 00:50:
[...]

Zou in het geval van de 'sort-by-reply'-switch de pubDate dan niet 'gewoon' leeggelaten moeten/kunnen worden om zo niet in de knoop te komen met de gemiddelde rss-readers?

In de eerste plaats vind ik het nut van de alternatieve sortering voor die feed niet erg groot, en ten tweede betekent dat ook een wijziging van de veld-mappping en ga je mogelijk nuttige data zelfs weglaten. Daarbij weet ik niet wat precies het gedrag is van de 'gemiddelde' rss-reader, ik weet wel dat Google Reader ook een optie heeft om te sorteren op datum.

RSS is en blijft een 'simple syndication' formaat, dus je kan niet verwachten dat je daarmee alle mogelijke views kan opvragen. Als je dat wilt dan moet je de XML-feeds gaan gebruiken (maar die zijn niet bruikbaar als gallery- of trackerfeed).

Wat mij betreft is dit dan dus ook een wontfix, en is het probleem van de topicstarter op te lossen door voor een topic altijd een feed te genereren met de laatste x replies aflopend gesorteerd. Dat laatste ben ik dan ook voornemens te fixen.

[Tassadar32]

Het omgekeerd sorteren in google reader 'op oudste sorteren' draait de feed inderdaad om. Zal kijken of deze dan ook goed geupdate word.

[crisp]

Tassadar32 schreef op maandag 29 maart 2010 @ 08:35:
Het omgekeerd sorteren in google reader 'op oudste sorteren' draait de feed inderdaad om. Zal kijken of deze dan ook goed geupdate word.

De vraag is dan nog welke feed-url je gebruikt; als je gewoon http://gathering.tweakers.net/rss/list_messages/1400603 gebruikt dan krijg je altijd maar de eerste pagina replies wat natuurlijk weer een probleem geeft bij topics met meerdere pagina's.

[Tassadar32]

Dat is inderdaad ook vervelend. Eigenlijk gebruik ik reader zodat ik niet alle sites af hoef te gaan en een flink aantal topics moet bekijken. Als ik 'last' feed pak dan heb ik zeker wel altijd de laatste replies?

[crisp]

Tassadar32 schreef op maandag 29 maart 2010 @ 08:41:
Dat is inderdaad ook vervelend. Eigenlijk gebruik ik reader zodat ik niet alle sites af hoef te gaan en een flink aantal topics moet bekijken. Als ik 'last' feed pak dan heb ik zeker wel altijd de laatste replies?

Ja, je zal (nu nog) /last moeten gebruiken

[Tassadar32]

Kleine update: Bij google zie je ook geen unread (nieuwe) items verschijnen ondanks dat die er wel zijn. Dit ondanks het feit dat de feed omgekeerd is in reader. Het blijkt dus dat een feed waar nieuwe items onderaan bijkomen niet goed functioneert. zelf dan maar even een scriptje schrijven om feeds te reversen?

[crisp]

Tassadar32 schreef op maandag 29 maart 2010 @ 10:55:
Kleine update: Bij google zie je ook geen unread (nieuwe) items verschijnen ondanks dat die er wel zijn. Dit ondanks het feit dat de feed omgekeerd is in reader. Het blijkt dus dat een feed waar nieuwe items onderaan bijkomen niet goed functioneert. zelf dan maar even een scriptje schrijven om feeds te reversen?

totdat ik dit in de feed zelf gefixed heb is dat dan denk ik inderdaad de enige oplossing...

[crisp]

list_messages feeds worden voortaan in omgekeerde volgorde (voor RSS de goede volgorde dus ) gebakken