nicht angemeldet
Hi,
Ein Browser auf einem Smartphone weiß nämlich sehr wohl, ob gerade eine GSM oder WLAN Verbindung genutzt wird.
bist du da sicher?
Ziemlich sicher ... ;-)
Siehe u.a.: https://developer.mozilla.org/en-US/docs/DOM/window.navigator.connection
Das würde bedeuten, dass die saubere Trennung zwischen Anwendungs- und Betriebssystemebene, die man auf herkömmlichen PCs anstrebt, bei den Smartphones absichtlich aufgeweicht wird. Das kann ich mir nur schwer vorstellen, zumal beispielsweise Android auf Linux basiert und daher auch nach dessen Grundarchitektur funktionieren müsste. Und das heißt nun mal: Der Browser (Anwendung) will eine Verbindung zu einem Remote-Host herstellen und fordert das OS auf, diese Verbindung aufzubauen. Wie und über welches Medium das OS das tut, bekommt die Anwendung normalerweise nicht mit.
Ich bin kein "Fachmann", was diese technischen Innereien auf Betriebssystemebene angeht, aber soweit ich das sehe & verstehe, stellt das OS eben entsprechende APIs bereit, über die der Browser halt diese Art Informationen erhält, bzw. abrufen kann.
Das nutzt aber nur knapp die Hälfte, wenn man als Autor nur per JS darauf zugreifen kann, denn viel "interessanter" wäre es ja, diese bereits serverseitig nutzen zu können, um bspw. spezielle low resolution images auszuliefern oder Images sogar nur rein auf Anforderung auszuliefern.
Was mich persönlich an dem heutigen "System" am meisten "stört" ist, dass es quasi nach dem Prinzip funktioniert, jeder kriegt erstmal pauschal alles geliefert, um sich dann das rauszupicken, was für ihn "passt". Das ist ziemlich ineffizient und verursacht auch enorm viel (eigentlich) unnötigen Traffic.
Und selbst wenn, dann könnte das immer noch zu erheblichen Fehleinschätzungen führen. Angenommen, die Browser auf meinem Notebook oder Desktop-PC würden Informationen über ihre Netzanbindung bekommen. Dann würden sie von einer LAN- oder WLAN-Verbindung ausgehen und eine Bandbreite in der Größenordnung von 100Mbit oder mehr annehmen. Ob es aber vom Router aus ebenso flott weitergeht, oder mit einer schwachen 2Mbit-DSL-Leitung, oder gar schnarchlahm über ISDN, wissen meine PCs nicht. Und die darauf laufenden Browser logischerweise auch nicht.
Im Mobilbetrieb ist der Rückschluss vom Übertragungsmedium auf die verfügbare Bandbreite ebenso trügerisch. Denn auch wenn ein Smartphone eine flotte HSDPA- oder LTE-Verbindung zur nächsten Basisstation "sieht", kann die tatsächliche Übertragungsrate trotzdem sehr niedrig sein - beispielsweise wenn die physikalisch mögliche Bandbreite auf viele Nutzer aufgeteilt werden muss.
Da hast du völlig Recht und ich stimme dir da auch zu. Es kommt halt immer darauf an, welche Rückschlüsse man aus irgendwelchen Informationen zieht. Ich denke da auch eher an zukünftige Konfigurationsmöglichkeiten seitens des Users, wie eben z.B. "bitte möglichst kleines Datenvolumen senden", wie er sie heute bereits mit dem Accept Language Header hat.
Hierzu plädiere ich seit geraumer Zeit dafür, dass die HTTP Header entsprechend geändert, bzw. erweitert werden.
Das würde nur helfen, wenn deine Annahme tatsächlich stimmt, dass Smartphone-Browser ihre Umgebungsbedingungen kennen, und selbst dann wäre die Aussagekraft gering.
Nicht unbedingt ..., wenn ich mir die aktuelle Situation bezüglich der Hi-Res oder "Retina Display" Image Geschichte betrachte, dann wäre alleine eine per HTTP Header übertragene Information über die (unveränderliche) Resolution/ Pixel Density eine Sache, mit der sich das Problem recht einfach lösen lassen ließe.
Nur um das nochmal in aller Deutlichkeit zu sagen: Speziell irgendwelche Angaben über die Bandbreite sind beliebig uninteressant. Denn neben den von dir bereits angesprochenen Punkten kommt auch noch hinzu, dass sich diese jederzeit sehr schnell, also selbst innerhalb eines Requests und dessen Antwort, ändern kann (man denke bspw. an einen User, der sich im Auto sehr schnell bewegt und dementsprechend seine Netzverbindung ggf. starken Schwankungen unterworfen ist).
Gruß Gunther
Matthias Apsel
Der Martin