Is die van jou groter?

Als ik zeg dat er een relatie zit tussen de titel van dit bericht en het bericht “Hij zakt weer af! (Ik bedoel mijn broek)” op frEdSCAPEs wordt het natuurlijk wel een heel vaag verhaal. Maar toch is het zo.
Size matters
De bestanden die ik hier en op de EduKast-website beschikbaar stel verschillen nogal in omvang. Maar in het algemeen zijn ze toch wel meerdere MB’s groot.
Dan is het handig om bij de link naar het bestand aan te geven hoe groot dat bestand is.
En omdat ik liever lui dan moe ben wil ik dat niet voor elke link handmatig gaan toevoegen.
Ik heb een tijdje geleden alweer een bestaande plugin voor Nucleus aangepast zodat die niet alleen een icoontje voor het bestand zet, maar ook erachter de omvang van het bestand weergeeft.

fopen()
Om de afmetingen van een bestand te achterhalen dat niet persé op de server zelf staat haal je natuurlijk niet elke keer het hele bestand over, maar alleen een klein stukje, de header. Daarin zoek je dan de informatie over de omvang en die informatie gebruik je.

Op de Servage-server deed ik dat met fopen(), maar Dreamhost staat niet toe dat je op die manier bestanden die niet lokaal staan ophaalt. In plaats daarvan moet je CURL gebruiken.

Nou was dat nog niet zo’n vreselijk probleem (dacht ik), want er stonden voldoende voorbeelden online van hoe je de dingen die ik voorheen met fopen() deed ook met CURL kon doen.
Een eerste probleem kwam ik met de Newsfeed-plugin tegen. Die haalde namelijk RSS-feeds op. Daarbij wordt vaak gebruik gemaakt van redirects en standaard doet CURL dat niet. Je moet dan even weten dat je curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1); moet gebruiken.

Remote Filesize CURL edition
Op de PHP-website staat in de reacties de code voor het bepalen van de afmetingen van een bestand dat niet op de server hoeft te staan, dus waar je op basis van een URL naar verwijst.

Toen ik die code invoegde in de plugin gaf hij maar bij één van de bestanden die ik op de voorpagina bekeek een omvang weer. Op andere plekken deed hij het ook, maar onduidelijk was waarom niet bij de meeste videobestanden.

Testen
Om er achter te komen wat er gebeurde heb ik de code daarom maar in een apart PHP-bestand gezet en gekeken wat het resultaat was bij verschillende bestanden. De links hieronder leiden naar twee bestanden die een verschillend resultaat geven:
* Header bij het ene bestand
* Header bij het andere bestand

Oorspronkelijk gaf alleen het eerste bestand een resultaat bij “size=”. De reden daarvoor is dat het script op zoek gaat naar het getal dat achter de tekst “Content-Range: ” staat. Maar de header van het tweede bestand bevat die tekst niet. Daarin staat wel “Content-Range: bytes 0-22630546/22630547”. En dus kon het script in de header die informatie niet vinden. Door het toevoegen van een tweede zoekopdracht wordt nou ook in die gevallen de omvang gevonden en vermeld.

De broek van Fred
Toen ik ging zoeken naar een verklaring voor dat verschil in header kwam ik bij deze pagina van het W3C over Content-Range. En daar werd ook de relatie met de broek van Fred Zelders duidelijk. Het bericht bij Fred ging namelijk over het feit dat Microsoft had aangegeven dat de in IE7 ingebouwde RSS-lezers alleen enclosures (van >15MB) zou ophalen van servers die ondersteuning hebben voor de Range header. Daarmee kan de download namelijk (ongemerkt voor de gebruiker) in stukken gehakt en gedownload worden.

Geruststellende gedachte is nu dus dat ik me geen zorgen hoef te maken over die beslissing aangezien Dreamhost daar al gebruik van maakt.
Wil je er zelf mee aan de slag, je kunt de broncode van het PHP-bestand downloaden.
zip Broncode
overigens, bovenstaande regel maak ik met:
<%Podcast(/Pierre/files/getsize.zip|Broncode)%>
Icoon en omvang worden dan automatisch gegenereerd.

0 0 stemmen
Bericht waardering
3 Reacties
Inline Feedback
Bekijk alle reacties
Fred Zelders
17 jaren geleden

Pierre,

Goeie waardevolle! post.

Ik hoop toch zo dat het bij mede bloggers de het besef triggert om
a) de omvang van (wat meer omvangrijke) downloads te publiceren om de verwachtingen te managen;
b) afbeeldingen in posts eerst in omvang te reduceren (zoals in photoshop ‘save for web o.i.d.’). Want wat dat betreft wordt er nog echt een potje van gemaakt.

Trouwens, zou het niet mooi zijn als een blogging tool elke afbeelding die in een post wordt gepubliceerd zelf al meteen optimaliseert voor het web?

Pierre
17 jaren geleden

Hoi Fred,

Eens wat betreft dat managen van verwachtingen. Zelfs als je een stevige downloadsnelheid hebt is het wel fijn om te weten wat je kunt verwachten. Maar het is niet leuk als je dat er elke keer zelf aan toe moet voegen.
Wat die totale omvang van plaatjes en zo betreft blijft het een moeilijkere afweging. Ik zit regelmatig met de vraag of een bestand niet te groot is om aan te bieden. Neem bijvoorbeeld deze post. Allemaal bestanden van ruim 20MB. Met 10Mbits/sec geen probleem, maar (als je overhead meetelt) duurt downloaden op één ISDN-lijn nog een uur (zie ook deze site voor een eenvoudige berekening). Maar verkleinen van deze video’s is niet zo eenvoudig.
Het is daarom jammer dat je voor automatische conversie naar Flashvideo gebruik moet maken van externe diensten als YouTube of Google Video (al begrijp ik dat Dreamhost nu sinds kort ook een AVI/MOV/MPEG/MPG to FLV converter heeft op hun server, dus er komt verbetering in!).

Bij plaatjes gaat het al wat beter. Als ik afbeeldingen op de server plaats (dus niet op Flickr) dan wordt er automatisch een kleinere versie gemaakt op het moment dat de afbeelding te groot is. Het originele bestand wordt dan met een hyperlink aan de kleine versie gekoppeld. Handmatig optimaliseren zou ik inderdaad echt niet willen gaan doen.

Maar het vergt wel dat je er heel erg mee bezig bent. En eigenlijk wil je gewoon uploaden, linken en klaar….

Fred Zelders
17 jaren geleden

Pierre,

Er zijn uiteraard grenzen aan de effort die je er in gaat stoppen. Verder is het uiteraard de keuze van de blogger zelf hoe ver ie daar mee wil gaan.
Ik merk echter dat er (te!) veel bloggers zijn die zich gewoon niet realiseren dat er met kleine moeite heel veel verbetering valt te bereiken.

P.S. Dank voor de ‘download time calculator tip’.
EenTopTip!