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:
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;
}
Om Peter MakholmKommentarer (6)
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!)
-
0 -
0
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.
-
0
-
0
Der kræves ikke et bestem præfix, det er selve navnet på namespacet der i WebDAV-standarden defineres til at være "DAV:"
-
0
-
0
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.
-
0
-
0
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 :)
-
0
-
0
Tilføj kommentar
