Få et gratis link til den nye mobile udgave af Version2
Elan IT Resource A/S
Elan IT Resource A/S
Elan IT Resource A/S
Top-Toy A/S
Unix-systemudvikler
Vær liberal med hvad du modtager
Når man implementerer protokoller er der en gammel tommelfingerregel der siger at man skal være liberal med hvad man modtager og konservativ med hvad man sender. Men det var nu lettere i gamle dage hvor mange protokoller lå direkte over en strøm at ascii-tegn.
I dag skal man ofte tage hensyn til en hel lagkage af standarder og en del af dem specificerer ligefrem at man skal være meget konservativ med hvad man modtager. Helt galt går det når de øverste dele af lagkagen bliver defineret mens de underliggende lag ikke er helt færdige.
Tag for eksempel en standard som WebDAV (RFC4918). Den anvender blandt andet XML pakket ind i HTTP. Som namespace har man valgt "DAV:". Senere, tror jeg nok, har XML-folkene besluttet at namespaces skal være strikte URI'er. Men det er "DAV:" ikke.
Hvad kan man gøre? Man kan ikke rigtigt ændre WebDAV-standarden og sikre bagudkompatibilitet og en del hylde-implementationer af XML følger rent faktisk standarden, hvilket gør dem ubruglige til at implementere WebDAV.
Så enten må man (re)-implementere hele standardstakken, eller også må man ty til grimme hacks, såsom at ændre namespaces med rå substitutioner mellem protokol-laget og XML-implementationen. Det sidste er det letteste, men det er ikke specielt tilfredsstillende at skulle gøre det. For eksempel i Perl:
I dag skal man ofte tage hensyn til en hel lagkage af standarder og en del af dem specificerer ligefrem at man skal være meget konservativ med hvad man modtager. Helt galt går det når de øverste dele af lagkagen bliver defineret mens de underliggende lag ikke er helt færdige.
Tag for eksempel en standard som WebDAV (RFC4918). Den anvender blandt andet XML pakket ind i HTTP. Som namespace har man valgt "DAV:". Senere, tror jeg nok, har XML-folkene besluttet at namespaces skal være strikte URI'er. Men det er "DAV:" ikke.
Hvad kan man gøre? Man kan ikke rigtigt ændre WebDAV-standarden og sikre bagudkompatibilitet og en del hylde-implementationer af XML følger rent faktisk standarden, hvilket gør dem ubruglige til at implementere WebDAV.
Så enten må man (re)-implementere hele standardstakken, eller også må man ty til grimme hacks, såsom at ændre namespaces med rå substitutioner mellem protokol-laget og XML-implementationen. Det sidste er det letteste, men det er ikke specielt tilfredsstillende at skulle gøre det. For eksempel i Perl:
sub escapeNamespace {
$_[0] =~ s/(xmlns(?::\w+)?)="(?!urn|http)([^"]+)"/$1="urn:xxx:$2"/g;
$_[0] =~ s/(xmlns(?::\w+)?)='(?!urn|http)([^']+)'/$1='urn:xxx:$2'/g;
$_[0] =~ s/(xmlns(?::\w+)?)=""/$1="urn:xxx:nonamespace"/g;
$_[0] =~ s/(xmlns(?::\w+)?)=''/$1='urn:xxx:nonamespace'/g;
}
PHP Frameworks
Det er en meget relevant problemstilling, du har fat i!
Vi vil fx gerne kunne eksportere kalenderfiler til Google Calendar, så det har jeg kigget en del på. Den er godt nok ikke lavet efter at være liberal i hvad den modtager. Hvis jeg husker ret, så var noget af det jeg boksede med et linieskift for meget efter det sidste END:VCALENDAR og fejlmeddelelsen? Nej, det ville være for nemt. Den nægter bare at godtage ens kalenderfeed indtil det er perfekt :-)
(Men vi endte med at få det til at virke, så sig til hvis I kender nogen, der har givet op for tidligt!)
Vi vil fx gerne kunne eksportere kalenderfiler til Google Calendar, så det har jeg kigget en del på. Den er godt nok ikke lavet efter at være liberal i hvad den modtager. Hvis jeg husker ret, så var noget af det jeg boksede med et linieskift for meget efter det sidste END:VCALENDAR og fejlmeddelelsen? Nej, det ville være for nemt. Den nægter bare at godtage ens kalenderfeed indtil det er perfekt :-)
(Men vi endte med at få det til at virke, så sig til hvis I kender nogen, der har givet op for tidligt!)
Hvor galt det kan gå, hvis man følger devicen om at være liberal i modtagelse, kan ses på udviklingen af browsere. I starten var browserne meget liberale, men det gjorde så også at en dårligt specificeret side i IE, så anderledes ud end i andre browsere. Det gav mulighed for at IE fik en lockin effekt, da de fleste sider blev skrevet specifik til IE. Det tog mange år at komme ud over det problem, og krævede at browsere er meget strikse i det de modtager, og fejler på en specificeret måde.
Der kræves ikke et bestem præfix, det er selve navnet på namespacet der i WebDAV-standarden defineres til at være "DAV:"
Jeg mener faktisk at hele ideen om 'Graceful degradation' var et at de succesfulde ting ved HTML, omend den aldrig var helt gennemført.
Det store problem der skabte MSIE-lockin var efter min opfattelse heller ikke at MSIE introducerede nye tags, men at folk forsøgte at bruge HTML som layout-sprog og krævede samme layout-præcision som de kunne i deres trykte pjecer.
Lad os få 'graceful degradation' tilbage på www. Det vil løse mange problemer.
Det store problem der skabte MSIE-lockin var efter min opfattelse heller ikke at MSIE introducerede nye tags, men at folk forsøgte at bruge HTML som layout-sprog og krævede samme layout-præcision som de kunne i deres trykte pjecer.
Lad os få 'graceful degradation' tilbage på www. Det vil løse mange problemer.
Der er stor forskel på om man laver graceful degradation og giver en gammel browser mulighed for at rendere visse dele af nyere sider og om man accepterer fejl i den standard som browseren var designet til at følge.
Det går som regel voldsomt galt hvis man ikke kan stole på hvad man modtager. Så eksploderer ens kodebase og man skal håndtere det ene specialtilfælde efter det andet. Derfor kan det bedst betale sig at afvise ting i døren hvis det ikke overholder en fast defineret standard.
I princippet burde en fejlbehæftet HTML-side give fejlbeskeder. Men - hvis siden ellers er korrekt, borset fra en række extra tilføjelser som browseren ikke forstår, så giver det nok mening at acceptere siden.
Liberal modtagelse er nemt nok i Perl, men heldigvis findes der mere fornuftige sprog en Perl :)
Det går som regel voldsomt galt hvis man ikke kan stole på hvad man modtager. Så eksploderer ens kodebase og man skal håndtere det ene specialtilfælde efter det andet. Derfor kan det bedst betale sig at afvise ting i døren hvis det ikke overholder en fast defineret standard.
I princippet burde en fejlbehæftet HTML-side give fejlbeskeder. Men - hvis siden ellers er korrekt, borset fra en række extra tilføjelser som browseren ikke forstår, så giver det nok mening at acceptere siden.
Liberal modtagelse er nemt nok i Perl, men heldigvis findes der mere fornuftige sprog en Perl :)
38- 2 timer siden - Steve Jobs tager fejl: Flash er ikke en processor-tyv (36)
- 5 timer siden - Psst! Tirsdag aften,det sædvanlige sted, sig det videre! (3)
- 6 timer siden - Så meget computer får du for 10.500 kroner i Københavns Kommune (38)
- 9 timer siden - SharePoint 2010 – det, kunderne (ikke) spørger om (1)
- 10 timer siden - HP's nye business-bærbare: Smil, og du er logget på (6)
- 14 timer siden - Børnehaver tvunget til 'billig' indkøbsordning: 10.000 kroner for en pc (34)
- 16 timer siden - It- og Telestyrelsen: Her er førstehjælpen til offentlige it-skandaler (3)
- 18 timer siden - DSB giver gratis internet på de lange togture (14)
- 21 timer siden - Microsoft taber Word-patentsag: Får ikke lov at appellere (24)
- 1 dag siden - Blond udvikler: "Jeg forstår ikke den her kode" (31)
Seneste indlæg i denne blog
12/02
Redaktionen anbefaler
