🚀 go-pugleaf

Użytkownik "porneL" <niusy3@pornel.net> napisał w wiadomości 
news:op.t6mkrze9c85zcd@aimac.local...

>> A to jest zdaje sie http a nie rss. I przeczytaj jeszcze raz - feedy sa
>> agregowane na zewnetrzym serwerze.
>
> Porządne czytniki agregują same i wtedy nie potrzebują, żeby serwer im 
> wysyłał wszystko za każdym razem.
>
>> BTW: Dopoki specyfikacja rss'a nie bedzie *wymagala* korzystania z tego
>> naglowka - bede twierdzil, ze to jeden z najbardziej szkodliwych 
>> wynalazkow, w ktorych uzywa sie xml'a.
>
> Specyfikacja RSS nie będzie, bo nie jest rozwijana i i tak ma tendencję do 
> dublowania ficzerów HTTP (np. <ttl> zamiast Cache-Control: max-age).
>
> Ale poprawna obsługa cache stoi w interesie serwujących feedy. Jeśli duży 
> transfer jest na prawdę problemem, to można dużo w tym temacie zrobić - od 
> pełnej obsługi cache, gzip i wysyłania częściowych feedów, po 
> rate-limiting skopanych klientów (to wszystko idzie po HTTP, więc masz do 
> dyspozycji User-Agent, mod_bandwidth, itp.)

Tyle, ze 95% fedow, nigdy nie bedzie miala taego zaimplementowane (bo nie ma 
wymagania).

Ale nawet jakby, to i tak nie zmieni to postaci rzeczy. Wiekszosc 
generowanego ruchu poswiecana bedzie na stwierdzanie, ze nie ma nic nowego 
do zassania.

Mozna by to zmniejszac agregujac feedy klienta na zewnetrznym serwerze 
(zamiast dwudziestu pytan jedno). Przy odpowiednio duzej liczbie 
uzytkownikow takiego serwera ruch generowany przez maszynerie bylby znaczaco 
mniejszy.

A jakby sie komus na prawde chcialo, to mozna by nawet do interesu nie 
dokladac (rankingi, ratingi i co tam markietoidy jeszcze wymysla).

Ale to by wymagalo pojscia ze standardem w kierunku umozliwiajacym, by nie 
rzec naklaniajacym, na dzialanie feedowych brokerow.

sz.