Scriptorama.nl

Het leuke van open-source projecten is ook dat je de ontwikkelingen op de voet kunt volgen. Zo ook met de Chrome browser van Google. Ze lijken bij Google niet alleen WebKit te gebruiken, maar er ook dezelfde instelling als de WebKit developers op na houden wat betreft het bedenken van nieuwe features & verbeteringen.

Uit de mailinglist van Chrome blijkt namelijk dat Google druk bezig is met een specificatie voor zogenaamde Background Browser Tasks én dat Google aan het testen is met een alternatief compressie algoritme voor HTTP verkeer.

Background Browser Tasks

Background Browser Tasks is op dit moment niet meer dan een idee waarmee het mogelijk zou worden om een bepaalde webpagina, zonder dat deze daadwerkelijk gerenderd wordt in een viewport, in geheugen actief te houden.

De pagina zou dus, zonder zichtbaar te zijn, volledig actief zijn en zou bijvoorbeeld met een XMLHttpRequest iedere minuut kunnen controleren of er iets belangrijks heeft plaatsgevonden, zoals bijvoorbeeld dat er een nieuwe email is binnen gekomen op je GMail account. Op dat punt zou de pagina de gebruiker op een bepaalde manier, zoals bijvoorbeeld via Growl, kunnen laten weten dat er een nieuwe email is.

Het idee van niet zichtbare pagina's die actief zijn, zal menig gebruiker enigzins angst zweet bezorgen maar uiteraard wordt er in het voorstel uitgebreid gesproken over hoe een website toestemming moet vragen aan de gebruiker voordat een dergelijke Background Browser Task zou worden gestart.

Op de mailing list van Google Chrome kun je meer lezen over het Background Browser Task voorstel en ook de voorgestelde User Interface alvast inzien. Wellicht zien we deze functionaliteit binnenkort terug in een beta van Google Chrome.

SDCH: Shared Dictionary Compression over HTTP

SDCH (Shared-Dictionary Compression over HTTP), of Sandwich voor vrienden, is een nieuw protocol dat is ontwikkeld binnen Google, dat beter om zou kunnen gaan met de realiteit van het serveren van webpagina's.

GZIP, het compressie algoritme dat momenteel het meeste wordt gebruikt voor het serveren van webpagina's, werkt op de basis van data die binnen de webpagina herhaalt wordt. Hier kan het GZIP algoritme winst behalen. Het 'probleem' hier mee is dat GZIP enkel op 1 request kan werken. Als je vanaf iets hoger naar browsen over een website kijkt, zie je dat je op een gemiddelde website elke keer dezelfde header, footer en andere onderdelen worden opgehaald.

SDCH probeert dit op te lossen door een manier te bieden om deze herhaalde elementen alvast aan de client aan te bieden in een compleet pakket, een dictionary. Deze wordt apart door de browser gedownload. Bij een volgende request, waarbij een browser dus aangeeft het dictionary te hebben, worden de elementen door het onderliggende DIFF algoritme (VCDIFF) in de response data vervangen met identifiers die refereren naar het dictionary en aan de hand daarvan stelt de client de uiteindelijke pagina weer samen. Deze individuele requests worden alsnog door GZIP gecompressed.

Op deze manier kun je inderdaad een aanzienlijke hoeveelheid data uit requests halen die in feite redundant wordt verzonden. De vraag is wel een beetje of dit praktisch blijft bij een behoorlijk dynamische site, maar het is in elk geval een interessant idee.

SDCH bevindt zich momenteel nog in een vroege testfase. Je kunt het wel al testen in recente testversies van Chromium, en op servers die SDCH ondersteunen: wat waarschijnlijk alleen Google.com is op dit moment ;).

Meer informatie vind je in de aankondiging van de testfase op de Chrome Developers lijst en in de specificatie voor het SDCH protocol (PDF).

Conclusie

Zowel Background Browser Tasks als SDCH zijn nog ver van ons bed. Voor gewone gebruikers zal het sowieso voorlopig onzichtbaar blijven. Desondanks is het interessant om eens te kijken en denken wat er met deze twee nieuwe technieken mogelijk zijn.

Met Background Browser Tasks zou een van de weinige overblijvende grote problemen van webapplicaties worden opgelost: het feit dat het einde verhaal is op het moment dat de gebruiker de website verlaat. De webapplicatie hoeft niet meer passief wachten tot er iets gevraagd wordt, maar zal veel meer actief kunnen bijdragen aan de workflow van een gebruiker.

SDCH zou eventueel ervoor kunnen zorgen dat een pagina request aanzien minder zwaar hoeft te worden, maar, het blijkt nog even bezien of het voordeel nog overeind blijft op het moment dat je een zeer dynamische pagina hebt.

Wat denk jij van deze ideeën?