Hallo
Nun ja, dem würde ich nur ein „vergiss es“ entgegnen wollen. Nur die allerwenigsten Benutzer würden das konfigurieren, also würde spätestens die Frage nach zeit- oder volumenbasierten Abrechnungen meist ins Leere laufen.
Erst mal müssten wir uns einigen, in welcher Stufe eine Kontrolle überhaupt sinnvoll ist.
…
Die nächste Stufe ist der Server. Dieser kann optional auf einen Header reagieren.
Hier geht's ja darum, auf Basis welcher Daten ein Browser einen solcher Header generieren sollte. Aus Messungen der Geschwindigkeit von Antworten auf Anfragen in der nahen Vergangenheit auf die vermutliche aktuelle Verbindungsgeschwindigkeit zu schließen, geht. Die Punkte Verbindungsart (LAN, WLAN, Mobilfunk (mit seinen sehr unterschiedlichen Geschwindigkeiten je naqch System)) und Tarife, sind aktuell nicht ermittelbar. Die Informationen für den Browser lesbar zu hinterlegen, ließe sich wohl für den Punkt Netzwerk automatisieren, für den Punkt Tarife wohl nicht. Da in meinem Szenario nur die wenigsten Benutzer soetwas selbst konfigurieren, bliebe diese Informationsquelle auf der Strecke.
Gehst du davon aus, dass eine solche Funktion datensparsam implementiert würde? Ich nicht.
Tja, wir haben da notorische Erfahrung, aber ja, ich denke, es kann eine datensparsame Information beschrieben werden. Der header ist ja nicht verpflichtend sondern beratend, so wie das auch für language Negotiation gilt. In diesem Fall ist die Information noch viel einfacher.
Wenn du von deinem ursprünglichen Ideal-response-max: 200kb
ausgehst, ja. Wie gut das funktionieren würde, wäre herauszufinden.
Tschö, Auge
Eine Kerze stand [auf dem Abort] bereit, und der Almanach des vergangenen Jahres hing an einer Schnur. Die Herausgeber kannten ihre Leser und druckten den Almanach auf weiches, dünnes Papier.
Kleine freie Männer von Terry Pratchett