Web development

Blogposts on blog.futtta.be about “web development”; looking into frameworks, security, best practices, the use of Flash, usability and accessibility, …

De volgende web (r)evolutie is hier (bijna)!

by

some logo, not telling you what it’s from though :-pWeb 2.0: been there, done that? En wat nu? Wel, Tim Berners-Lee en andere visionairen beweren dat de toekomst van het web semantisch zal zijn. Waarmee ze bedoelen dat informatie op het web betekenis moet krijgen voor machines (software), zodat die zelf verbanden kunnen leggen om die verzamelde data dan aan de gebruiker te presenteren. Het idee van Tim Berners-Lee is ondertussen al meer dan 5 jaar oud en er is in de praktijk eigenlijk nog niet veel gebeurd op het vlak van het semantische web. Maar nu lijkt er een doorbraak op til met een elegante en betrekkelijk eenvoudige oplossing om web-data te structureren.

microformats logo De volgende web (r)evolutie zou dan ook wel eens kunnen worden ontketend door microformats. Dat is informatie in gewone web-pagina’s die in de html-code extra getagged wordt, om diezelfde pagina ook voor machines en software bruikbaar te maken. Een heel eenvoudig voorbeeld met een gewone link:

<a href=”http://e-cafe.be/frank/”>frank goossens</a>

een beetje aanpassen naar

<div class=”vcard”><a href=”http://e-cafe.be/frank/” class=”url fn”>frank goossens</a></div>

en mijn naam en de url van mijn (shabby) homepage zijn ontsloten middels de hcard-microformat en daarmee ook “machine-readable”! Voor hcard zijn er nog veel andere attributen (adres, geboortedatum, nickname, foto, …) en daarnaast zijn er ook microformats voor bv. kalenderinformatie (hcalendar), recensies en tags. In die laatste incarnatie worden microformats overigens nu al ondersteund door zowat alle blogsoftware.
Ja, en dan?
En wat kunt ge daar dan mee Goossens? Awel; de gestructureerde informatie in microcards kan in principe gelezen worden door je browser, door zoekmachines of door andere gespecialiseerde software. En daar kan die data aangevuld worden met andere gestructureerde informatie om al dat moois dan voor uw en mijn gebruiksgemak te presenteren. Het valt bijvoorbeeld te verwachten dat zoekrobotten (technorati heeft dit al in de keuken staan) microformat-informatie zullen verwerken en gebruiken om zoeken op iets als “alle events in Gent van 14 tot 23 juli” in kalender-formaat mogelijk te maken. Of dat je browser microformats herkend en je die rechtstreeks in je contact-, kalender-applicatie of in google earth/ maps kunt binnenhalen (spoiler: dat kan nu al, lees vooral verder).
Veel beter uitgelegd
Vorige maand hield FF-user experience designer Alex Faaborg een presentatie over microformats die in dit kader zeker mag gezien worden (link naar slideshare-presentatie).
De doorbraak
operator screenshotMicroformats bestaan ondertussen 2 jaar, maar er zijn een paar stevige redenen waarom de doorbraak er in 2008 zit aan te komen; ze zitten dus in Firefox 3 en Internet Explorer 8 zal die vermoedelijk ook ondersteunen (Gates gaf zijn zegen in 2006). Er is overigens nu al een microformats extensie beschikbaar voor Firefox 2; Operator, ontwikkeld door een IBM-developer, dat kan ook al tellen als geloofsbrief. Operator vormt overigens de basis van de microformats-ondersteuning in FF3.
Anderzijds lijkt er ook aan de kant van websites ook wat te bewegen: sites als upcoming.org, plaxo, salesforce en linkedin bieden hun info nu al via microformats aan. Aan de kant van “website beheer software” zijn ontwikkelaars van open source systemen als Drupal, MediaWiki en WordPress microformats aan het integreren. Het lijkt me niet meer dan logisch dat dit een selectiecriterium voor keuze van corporate webcms’en zal worden (waarbij CMS’en die op basis van contenttypes werken, duidelijk in het voordeel zijn).
Hoort U het ook?
Wat ajax gedaan heeft voor web 2.0, zullen microformats voor <insert buzzword here> doen; met betrekkelijk eenvoudige technologie de basis leggen van ontwikkelingen die het web naar een volgend niveau kunnen tillen. Wie een site beheert waar contact-gegevens of gebeurtenissen op gepubliceerd worden, heeft de klok horen luiden, ga nu uw klepel zoeken!
Meer info:

5 tips voor succes op het web

by

Ik ben voor mijn werk aan een presentatie over functionele en technologische keuzes voor websites bezig. Als basis voor die keuzes, stel ik, moeten de redenen van het succes van het internet genomen worden, want die gelden even goed ook voor individuele websites. Zo voor de vuist weg (niet echt, ik ben hier al een tijdje over aan het prakkiseren) kan ik er een 5-tal bedenken:

  1. Geef de mensen informatie!

    2. Daar draait het op het web immers om, informatie. Dus niet over hoe leuk het er allemaal uit ziet (al is dat altijd mooi meegenomen), niet over een promootje op je webshop en ook niet over CPC van je Google Adwords campagne. Nee, het draait in eerste instantie echt gewoon over ‘kwalitatieve content’, over ‘inhoud’. De mensen willen internet om dezelfde redenen als waarom onze verre voorouders vroeger encyclopedieën kochten; omwille van de belofte dat je, als je dat wilt, informatie onmiddellijk ter beschikking hebt.
    tip 1: Zorg voor kwalitatieve informatie waar je doelgroep iets aan heeft.

  2. Gratis is nooit te duur

    3. Inhoud is koning, keizer, admiraal, maar verwacht niet dat gebruikers voor ‘gewone informatie’ zomaar geld zullen neertellen. De grote succesverhalen op het web zijn niet toevallig geheel of gedeeltelijk gratis. Google, Youtube, Wikipedia, die duizenden internet-fora … allemaal gratis inhoud.
    De truc voor wie toch geld wilt vragen voor zijn “content”, is een evenwicht te vinden tussen je gratis en je betalend aanbod. LinkedIn is een goed voorbeeld; iedereen kan zonder een eurocent uit te moeten geven lid worden en je kunt met zo’n gratis account perfect online netwerken. Maar terwijl je, blij als een kind met deze toffe gratis dienst, je online netwerk beetje bij beetje verder uitbouwt, voeg je zelf ook informatie (en nieuwe gebruikers) toe. Eenmaal je goed en wel op weg bent, schrijf je misschien ook een aanbeveling of beantwoord je vragen in de ‘answers’ sectie. Gratis informatie geven en nemen, in ieders voordeel. Alleen voor een klein een deel van de meest sexy functionaliteit tenslotte (de volledige lijst van wie je profiel bekeken heeft bv.), moet je wel betalend lid zijn. Online uitgevers zoals De Standaard en de muziek- en filmindustrie lijken overigens nog te worstelen met het vinden van de juiste verhouding tussen gratis en betalend.
    tip 2: Geef je bezoekers die informatie ten minste gedeeltelijk gratis.

  3. “Wie doet er mee, internetteke?”

    4. Internet drijft dus op gratis inhoud, maar wat meer is: iedereen mag meedoen! Wie toegang tot internet en een browser heeft, kan mee zoeken en lezen, maar kan vooral ook mee schrijven en linken. Het internet is op die manier vanzelf viraal; je leest, je reageert, je schrijft zelf, je stuurt linken door, … Het succes van internet en van succesverhalen als Youtube, Wikipedia, Facebook en dichter bij huis van bv. de Telenet Games-fora (nu geïntegreerd in 9lives.be) is dan ook mee te danken aan het feit dat iedereen mag meekijken, meespelen en mee promoten. Het internet, dat zijn de mensen. Vergeet die hippe marketeers en trendwatchers dus maar; het internet is vanaf de allereerste site (van Tim Berners-Lee aan de CERN in Genève, zie zijn oproep om zelf content te publiceren of software te schrijven in ‘How can I help‘) altijd al een viraal en sociaal medium geweest!
    Dat iedereen mag meedoen, gaat inderdaad verder dan het puur inhoudelijke: ge kunt, als ge na het lezen van dit artikel een geweldig idee hebt, onmiddellijk beginnen om nieuwe spannende software voor het web te schrijven. Internet en het www zijn immers gebaseerd op open, gestandaardiseerde technologie (tcp/ip, smtp, http, html, …) waar geen rechten op betaald moeten worden. Daarnaast heeft ook het succes van het open source ontwikkelmodel sterk bijgedragen tot de grote hoeveelheid beschikbare kwalitatieve software voor het internet (denk aan Bittorrent, Firefox, Apache, WordPress, Drupal, Mediawiki, …) en op die manier voor het succes van het web in zijn geheel.
    Voeg het idee van open communicatie en open software development tenslotte samen en “shake firmly” tot je een mashup hebt; web-applicaties (zoals Amazon en Google Maps), social-networking-sites (zoals het al vermeldde Facebook en binnenkort ook Linkedin) en andere web2.0-software projecten (opnieuw; Drupal, WordPress, Mediawiki, Joomla, …) laten ontwikkelaars toe om met behulp van een API (application programming interface) widgets, extensions en plugins te schrijven die extra functionaliteit in hun sites integreren of die informatie van hun site halen om ze in een andere context (bv. iGoogle of live.com of rechtstreeks in je browser) te publiceren. Het resultaat: gratis extra functionaliteit voor je bezoekers!
    tip 3: zet je website “wijd open”; een standaard browser moet voldoende zijn, moedig het linken naar je content en gebruik van je rss-feeds aan, bevorder communicatie op en/of over je site en overweeg de mogelijkheid van het openstellen van je applicaties voor “amateur-ontwikkelaars”.

  4. Uw grootmoeder kan het!

    5. Een oppervlakkige kennis van computers is voldoende om het internet op te trekken. Computer opstarten, icoontje van je browser klikken, naar Google, zoekterm intikken, à volonté op al die hyperlinks klikken, ge moet daar niet voor gestudeerd hebben mijnheer! Verkeerde pagina? Eén klik op de back-knop en je zit terug in je zoekresultaten (het web is sequentieel, ge gaat van pagina A naar B naar C terug naar B naar D, …) en als je een toffe pagina hebt gevonden; in de bookmarks ermee! Dat is het. Indien surfen niet zo eenvoudig zou zijn, hadden de webbouwers en -marketeers onder ons nu niet zo een fijne job.
    Om die drempel zo laag te houden, moeten sitebouwers zich wel een beetje aan de standaarden (html, css, …) en conventies (links zijn onderlijnd, elke pagina heeft zijn unieke URL zodat er kan gebookmarket en gelinkt worden, back-toets werkt, goeie navigatie en interne search …) houden. Wijk nooit af van webstandaarden en -conventies, zelfs niet als het nifty UI-alternatief van dat flashy webagency voor jou, doorwinterd webexpert die je bent, best eenvoudiger en vooral zo veel leuker lijkt.

    tip 4: laat je website volgens de regels van de kunst maken en hou het eenvoudig. Consistentie, eenvoud, usability, accessibility. Geloof me, ge kunt niet zonder en uw grootmoeder al zeker niet!

  5. Wie zoekt die surft (en surft en surft en …)

    6. Met die schier oneindige hoeveelheid aan gratis informatie zouden we niet veel zijn zonder tools om al die pagina’s makkelijk terug te vinden. Van Webcrawler en Lycos mid jaren ’90 over Altavista tot Google; search engines zijn de alfa en de omega van zowat elk internet-bezoek (bij hoeveel mensen zou een search-engine de homepage zijn?).
    Indien je wilt dat je site makkelijk te vinden is, zul je ervoor moeten zorgen dat de zoekrobotten van bv. Google je site makkelijk kunnen vinden en indexeren. En om goed geïndexeerd te kunnen worden, zul je ervoor moeten zorgen dat je site web-standaarden en -conventies volgt (zelfs niet als dat flashy webagency … ge weet wel).
    tip 5: Consistentie, eenvoud, usability, accessibility; ge kunt niet zonder en de Googles out there zeker niet! wees vriendelijk voor Google en de bezoekers zullen tot U komen.

Natuurlijk is dit lijstje niet volledig en vanzelfsprekend is er heel wat meer nodig om succesvol op het internet te ondernemen (een goed business-plan helpt). Maar als het op rauwe trafiek aankomt: zet gratis kwalitatieve informatie open en bloot voor iedereen online, zorg ervoor dat die volgens de standaarden en conventies ontsloten wordt en verwelkom search-engines met open armen. Hoe het geld dan moet binnenrollen, dat mag U zelf uitvissen.
Interessante links en inspiratie:

Stoute wordpress upgrade maakt posts van pages?

by

Outro_Spective had gisteren een probleempje met zijn upgrade naar de laatste versie van WordPress op animobrugge.be; alle pages waren plots posts.


De oplossing bleek gelukkig betrekkelijk eenvoudig: posts en pages worden beiden in de ‘wp_post’ tabel bijgehouden in de wordpress database. Als je van de verdwenen pages in kwestie het ‘post_type’ van ‘post’ naar ‘page’ verandert, is alles terug in orde. Volgend sql-statement doet dat in 1 klap:

UPDATE wp_posts SET post_type = ‘page’ WHERE ID IN (x,y,z)

met in de plaats van x,y en z de id`s (het nummer na p= of page_id= parameter in de url van je posts/ pages) van de posts die terug page moeten worden

Waarmee dat Jong Links Brugs geweld terug foutloos online staat en ze zich nu terug volop met de politiek kunnen bezighouden 🙂

futtta vist nu ook in het engels

by

big babelfishGe hebt het misschien al gezien (behalve de feedreader-crowd dan, maar die lezen het nu dus); ik heb een link toegevoegd om deze pagina’s op eenvoudig muisklik-verzoek automatisch in het Engels te laten vertalen. Akkoord, die vertalingen geven meestal maar een vage -en niet zelden humoristische- benadering van de originele tekst, maar die paar internationale bezoekers op zoek naar een poging tot howto’s kunnen er hun voordeel maar bij doen, niet?
Aangezien Altavista Babelfish (Ave Digital) de moeder van alle online vertalingstools is en omdat Google Translate voorlopig niet in de buurt komt qua aangeboden talenparen, gebruiken we de Vis voor onze verovering van de wereld.
Hoe van deze wordpress.com-blog naadloos naar Babelfish switchen? Wel, normalerwijze zou een klein stukje javascript kunnen volstaan, iets als het volgende bijvoorbeeld:

<a href=”javascript:orig_url=document.location; target_url=’http://babelfish.altavista.com/babelfish/tr?’+orig_url+’&lp=nl_en&btnrUrl=Translate’; document.location=target_url;”>vertaal me</a>

Maar op wordpress.com kunt ge zelf geen javascript invoeren (wat niet slecht is, voor ge het weet zit uw favoriete blogplatform met cross-site-scripting issues), dus dan moet een mens zijn plan trekken met gewone html.
De uiteindelijke oplossing is bijzonder eenvoudig: de translate-link gaat naar een php-scriptje op mijn linux-serverke. Dat script pikt de referer uit de $_server variabele, test of die in de lijst met toegestane domeinen zit (*) en doet, als dat domein snor zit, een redirect naar Babelfish waar de vertaalvisjes onmiddelijk aan het werk gaan. Met dank aan Systran, het Franse bedrijf dat instaat voor de eigenlijk vertaalsoftware, overigens.
(*) Ik heb vooralsnog geen ambitie om vertalings-gateway worden voor Jan, Pier en Pol. Pas op, als die jongens ergens een php-scriptje kwijt kunnen, wil ik hun dat wel bezorgen. En als ze het echt heel vriendelijk vragen (ik drink graag Trappistenbier, Chimay Triple valt tegenwoordig heel goed in de smaak), zou ik hen zelfs kunnen toevoegen aan dat lijstje toegestane domeinen.

Onclick event handler in A HREF’s?

by

De collega’s van marketing willen bij sommige URL’s onclick event handlers laten toevoegen die elke klik loggen bij een web analytics aanbieder. De Onclick-javascript functie haalt wat gegevens op en voegt die toe aan een request voor een -onzichtbare- image.
Mijn eerste gedacht; niet doen, de onclick wordt eerst uitgevoerd en als de request voor die image te lang duurt (op basis van onze ervaring gingen we uit van ongeveer 0,6 seconden) moet de gebruiker ook extra lang wachten op de pagina die hij/zij opvroeg (want eerst onclick en dan pas request voor de feitelijke pagina in de href). Ik leek hier ook bevestiging voor te vinden op quirksmode dus niet doen?
Dit weekend begon ik me echter af te vragen of dit wel kon kloppen; alle wordpress-blogs bijvoorbeeld, houden klikgedrag op ongeveer die manier (wel niet de traditionele onclick, maar met echte events) bij. En die web analytics aanbieder, zouden die zoiets in productie zetten als dat een probleem zou zijn? Een testje dan maar, met volgende code:

<html>
<head>
<script>
function exec_me() {
//bust cache
rnd=Math.floor(Math.random()*1000000);
url=’http://florentsmet.be/distel.jpg?n=’ + rnd;
//wait a few seconds and then fetch image
setTimeout(“loadimg(url)”,192);
}
function loadimg(url) {
//declare image
var i=new Image(1,1);
//load image
i.src=url;
}
</script>
</head>
<body>
<a href=”http://www.google.com/” onClick=”exec_me();”>gogoogle</a>
</body>
</html>

Ik ga dan in de logs van florentsmet.be (site van mijn vrouwken over haar overleden grootvader die kunstschilder was) kijken en zie dat die image in FF perfect geladen wordt als die timeout op een laag cijfer staat (onder de 190 milliseconden) en nooit als die boven die 195 ms. In MSIE lijkt 215 zo een beetje het punt tot waar dat werkt.
Is dat nu een race-condition? En hangt die dan af met welke browser je werkt? Heeft iemand hier ervaring mee, of een paar goeie links waarin dit beschreven wordt? En vooral, op basis van deze tests zou ik besluiten dat die onclick-logging van geklikte links geen probleem is. Iedereen akkoord daarmee dan?

Integratie van externe content of applicaties

by

Hoe integreer je externe content (of applicaties) het beste? Ik ga hier de komende tijd even induiken met wat eenvoudige demo’s en lijstjes met pro’s en con’s, maar ik zie alvast volgende mogelijkheden:

  1. server-side binnenhalen en alles in 1 html-pagina naar de browser duwen
  2. in een popup steken
  3. in een iframe zetten
  4. in een div en die vullen met behulp van een stukje ajax

De keuze voor een bepaalde oplossing hangt ongetwijfeld af van een aantal factoren:

  • is de externe content statisch of dynamisch
  • wordt die externe content snel of traag ‘opgediend’
  • is de content echt extern (i.e. van een ander domein) of gaat het over een ‘lokale’ applicatie die los van de rest van de content staat
  • wat is de impact op usability
  • wat is de impact op “searchability”

Soit, veel vragen maar nog geen mooie antwoorden (wel vage ideeën en enkele vooroordelen). Iedereen die hier een mening over heeft of links naar goeie info kent: schieten in de comments graag (staan sinds kort open voor iedereen). Ik ben er U -zoals steeds- eeuwig dankbaar voor en in ruil mogen jullie dan binnenkort een samenvatting van mijn bevindingen verwachten 🙂

Levend vanop Webtech2007

by

Zit vandaag op Webtech 2007, een congres dat door cms-channel.be wordt georganiseerd. Heb er al een paar presentaties opzitten en terwijl Philip Achten de toehoorders de BIAC-case door de strot duwt, even de highlights tot nu toe opsommen:
Luc Van de Velde Director Developer & Platform group Microsoft Belgium had het over “Merging design and development in a 2.0 world”. Slotsom: MS biedt framework om aan alle behoeften te voldoen. Interessantste vond ik eigenlijk MS Silverlight, vroeger WPF/E, een browser-plugin (voor Windows en Mac, MSIE, Firefox, Opera, Safari, …) en vooral flash-killer. Maar daar kon/ wilde de man nog niet veel over vertellen, volgende week was het een grote conferentie daarover in Las Vegas.
Volgende spreker was Edwin Mol, freelance webdeveloper, zijn firma heet Siteware. Hij had het over de keuze van een framework en focuste daarbij op open source oplossingen. Naast Ruby on Rails had hij het vooral over een paar Java-frameworks, waaronder Google Web Toolkit, OpenLazlo, Wicket en Rife. Hij was vooral enthousiast over Rife, nadien nog even met hem gebabbeld en dat is een open source project van een Vlaming (moet nog opzoeken wie). Rife is stateless en component-oriented (in tegenstelling tot struts dat dan response/request-based is). Door middel van metadata die je aan je classes toevoegt, kun je -als ik het goed begrepen heb, ge kent mij- database-schema genereren en ook client-side validatie automatisch uit laten voeren door het framework. Veel meer info over Rife features staat hier. Wicket zou ook interessant zijn, is een open source framework van een Nederlands bedrijf blijkbaar, de volgende spreker had het daar ook over.
Voor de koffie-pauze hadden we nog een Nederlandse Apache en Java-guru op het programma; Ate Douma van Hippo. Hippo is een Nederlands bedrijf dat een open source CMS heeft en sinds kort ook een Portal oplossing. Moet hem straks nog eens aanspreken over wanneer hij vindt dat Portal-technologie ingezet moet/ kan worden. Zijn voorbeeld was alleszins ook weer voor een typisch intranet. Hij had het ook over de nieuwe portlet-specificaties (maar eentje onthouden; portlets asynchroon laden via ajax).
De mannen van Javablackbelt hebben ons hier op 20 minuten een cursus Hibernate gegeven. En straks proberen ze dat opnieuw, maar dan met Spring. Waarom ze dat doen? Omdat ze eigenlijk een developer knowledge website hebben, gratis voor developers maar betalend voor normale mensen. Ik snapte er geen bal van en toen ze kwamen vragen of ik een testje wilde komen afnemen (waarmee een blauw t-shirt te winnen viel) heb ik vriendelijk bedankt. Thomas en ik gaan pachten wel verplichten om zijn (verstofte) java-kennis te bewijzen 😉
Microsoft probeert ons nu, bij monde van Gunter Staes, te overdonderen met het gemak waarmee met Xaml, WPF, Ajax, Blend (een editor voor rich internet applications, beetje tegenhanger van flash/flex. De demo’s zijn straf, die Silverlight lijkt een krachtige plugin. Maar waarom naast Flash nog iets anders gebruiken? Beats me..
Terwijl de wireless hier wegviel, verliet Gunter Staes het podium en nam Noel Jaffré van Fatwire over. Hij had het over sattelite caches. Eigenlijk beschreef hij hier een door Fatwire gepatenteerde oplossing waarbij op ‘sattelite servers’ pagina componenten gecached worden ipv hele pagina’s. Niet helemaal duidelijk, maar lijkt erop neer te komen dat die sattelite servers eigenlijk minimale Fatwire presentatie logica bevatten en dat die, als een component niet beschikbaar is, dat aan het achterliggende systeem gaan vragen. Niet slecht, maar geen rocket science ook?
En dat was het voor mij, ik laat de Spring-cursus (zijn zelfs 2 sessies over) aan mij voorbijgaan. En de slides over GWT krijg ik wel, hopelijk.

Cache header magic (or how I learned to love http response headers)

by

Is your site dead slow? Does it use excessive bandwidth? Let me take you on a short journey to the place where you can lessen your worries: the http-response-headers, where some wee small lines of text can define how your site is loaded in cached.
So you’re interested and you are going to read on? In that case let me skip the foolishness (I’m too tired already) and move on to the real stuff. There are 3 types of caching-directives that can be put in the http response: permission-, expiry- and validation-related headers:

  1. Permission-related http response headers tell the caching algorithm if an object can be kept in cache at all. The primary way to do this (in HTTP/1.1-land) is by using cache-control:public, cache-control:private or cache-control:nocache. Nocache should be obvious, private indicates individual browser caches can keep a copy but shared caches (mainly proxies) cannot and public allows all caches to keep the object. Pre-http/1.1 this is mainly done by issuing a Last-Modified-date (Last-Modified; although that in theory is a validation-related cache directive) which is set in the future.
  2. The aim of expiry-related directives is to tell the caching mechanism (in a browser or e.g. a proxy) that upon reload the object can be reused without reconnecting to the originating server. These directives can thus help you avoid network roundtrips while your page is being reloaded. The following expiry-related directives exist: expires, cache-control:max-age, and cache-control:s-maxage. Expires sets a date/time (in GMT) at which the object in cache expires and will have to be revalidated. Cache-control:Max-age and Cache-control:s-maxage (both of which which take precedence if used in conjunction with expires) define how old an object may get in cache (using either the ‘age’ http response header or calculating the age using (Expires – Current date/time). s-maxage is to be used by shared caches (and takes precedence over max-age there), whereas max-age is used by all caches (you could use this to e.g. allow a browser to cache a personalised page, but prohibit a proxy from doing so). If neither expires, cache-control:max-age or cache-control:s-maxage are defined, the caching mechanism will be allowed to make an estimate (this is called “heuristic expiration“) of the time an object can remain in cache, based on the Last-Modified-header (the true workhorse of caching in http/1.0).
  3. Validation-related directives give the browser (or caching proxy) a means by which an object can be (re-)validated, allowing for conditional requests to be made to the server and thus limiting bandwith usage. Response-headers used in this respect are principally Last-Modified (date/timestamp the object was … indeed modified the last time) and ETag (which should be a unique string for each object, only changing if the object got changed).

And there you have it, those are the basics. So what should you do next? Perform a small functional analysis of how you want your site (html, images, css, js, …) to be cached at proxy or browser-level. Based on that tweak settings of your webserver (for static files served from the filesystem, mostly images, css, js) to allow for caching. The application that spits out html should include the correct headers for your pages so these can be cached as well (if you want this to happen, off course). And always keep in mind that no matter how good you analyze your caching-needs and how well you set everything up, it all depends on the http-standards (be it HTTP/1.0 or 1.1) the caching applications follows (so you probably want to include directives for both HTTP/1.0 and 1.1) and how well they adhere to those standards … Happy caching!
Sources/ read on:

(Disclaimer: there might well be some errors in here, feel free to correct me if I missed something!)