---

Hej

Jeg har en kode der behandler data fra en URL og det virker fint på min
bærbar, men når jeg flytter den til min server virker den ikke længere, men
smider en exception.
Koden er der virker/fejler er:

<-----KODE START----->

try
{
URL yahoo = new URL(_url);
BufferedReader in = new BufferedReader(
new InputStreamReader(
yahoo.openStream()));

String inputLine;

while ((inputLine = in.readLine()) != null)
System.out.println(inputLine);

in.close();
}
catch(Exception e)
{
System.out.println("Du kan stadig ikke kode Java din cowboy!!!");
System.out.println(e.toString());
}

<-----KODE SLUT----->


Når den fejler er outputtet:

Du kan stadig ikke kode Java din cowboy!!!
java.net.UnknownHostException: ssl.gratisdns.dk


Nogen der kan forklare mig hvad der er galt?

--
MooreHojer

---

MooreHojer wrote:
> Jeg har en kode der behandler data fra en URL og det virker fint på min
> bærbar, men når jeg flytter den til min server virker den ikke længere, men
> smider en exception.

> URL yahoo = new URL(_url);
> BufferedReader in = new BufferedReader(
> new InputStreamReader(
> yahoo.openStream()));

> catch(Exception e)
> {
> System.out.println("Du kan stadig ikke kode Java din cowboy!!!");
> System.out.println(e.toString());
> }

> Du kan stadig ikke kode Java din cowboy!!!
> java.net.UnknownHostException: ssl.gratisdns.dk

Den kan ikke finde ssl.gratisdns.dk i DNS !

Den eksisterer dog:

Name: gratisdns.dk
Address: 213.173.243.10
Aliases: ssl.gratisdns.dk


Men prøv og check DNS opsætning på det system hvor den ikke virker.

Arne

PS: Er det ikke super god vildledning af maintenance programmørerne
at kalde en URL til gratisdns.dk for yahoo ??

---

> Men prøv og check DNS opsætning på det system hvor den ikke virker.

Det var der fejlen lå.
Serveren er lige blevet installeret og ham der har sat DNS op har sat den op
med en DNS-server der ikke længere er i brug. Det er nu rettet og programmet
kører fint og uden fejl.

Takker!

--
MooreHojer

---

On 2008-02-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> Den kan ikke finde ssl.gratisdns.dk i DNS !

I øvrigt er URL-implementationen lettere hjernedød, fx er equals() og
hashCode() helt ude i hampen. Se siderne 11-17 i
http://developers.sun.com/learning/javaoneonline/2007/pdf/TS-2707.pdf
eller videoen på
http://video.google.com/videoplay?docid=9214177555401838409

Man kan dog sige at det i OPs tilfælde ikke har ret meget relevans, men
det er god baggrundsinfo at have med.

--
Andreas

---

> eller videoen på
> http://video.google.com/videoplay?docid=9214177555401838409

interresant

--
MooreHojer

---

Andreas Plesner Jacobsen wrote:
> http://video.google.com/videoplay?docid=9214177555401838409

Avavavavav. Fy for dælen. Hvem her i gruppen er klar over at
URL-klassens equals-metode er så godt som ubrugelig?

Mvh. Michael.

---

Michael Zedeler skrev den 17-02-2008 20:32:
> Andreas Plesner Jacobsen wrote:
>> http://video.google.com/videoplay?docid=9214177555401838409
>
> Avavavavav. Fy for dælen. Hvem her i gruppen er klar over at
> URL-klassens equals-metode er så godt som ubrugelig?

Jeg vidste det ikke, men til gengæld ville jeg nok også bede om en
kanonisk strengrepræsentation og sammenligne på den, istedet for at
samemnligne rå objekter. String.equals() har jeg efterhånden styr på :)

--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

On 2008-02-17, Thorbjørn Ravn Andersen <thunderaxiom@gmail.com> wrote:

>>> http://video.google.com/videoplay?docid=9214177555401838409
>>
>> Avavavavav. Fy for dælen. Hvem her i gruppen er klar over at
>> URL-klassens equals-metode er så godt som ubrugelig?
>
> Jeg vidste det ikke, men til gengæld ville jeg nok også bede om en
> kanonisk strengrepræsentation og sammenligne på den, istedet for at
> samemnligne rå objekter. String.equals() har jeg efterhånden styr på :)

Men der er vel strengt taget URI'er, der har forskellige
strengrepræsentationer men alligevel burde betragtes som ens. Et
eksempel, som URI.equals() kan håndtere er at scheme ikke er
case-sensitive.

--
Andreas

---

Andreas Plesner Jacobsen skrev den 17-02-2008 21:27:

> Men der er vel strengt taget URI'er, der har forskellige
> strengrepræsentationer men alligevel burde betragtes som ens. Et

Hvis du ved den slags, skriver du din egen sammenligningskode.
--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

On 2008-02-17, Thorbjørn Ravn Andersen <thunderaxiom@gmail.com> wrote:
>
>> Men der er vel strengt taget URI'er, der har forskellige
>> strengrepræsentationer men alligevel burde betragtes som ens. Et
>
> Hvis du ved den slags, skriver du din egen sammenligningskode.

Hvorfor det? URI ved det allerede.

--
Andreas

---

Andreas Plesner Jacobsen skrev den 17-02-2008 22:22:
> On 2008-02-17, Thorbjørn Ravn Andersen <thunderaxiom@gmail.com> wrote:
>>> Men der er vel strengt taget URI'er, der har forskellige
>>> strengrepræsentationer men alligevel burde betragtes som ens. Et
>> Hvis du ved den slags, skriver du din egen sammenligningskode.
>
> Hvorfor det? URI ved det allerede.

Eksempel tak.

--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

On 2008-02-17, Thorbjørn Ravn Andersen <thunderaxiom@gmail.com> wrote:

>>>> Men der er vel strengt taget URI'er, der har forskellige
>>>> strengrepræsentationer men alligevel burde betragtes som ens. Et
>>> Hvis du ved den slags, skriver du din egen sammenligningskode.
>>
>> Hvorfor det? URI ved det allerede.
>
> Eksempel tak.

System.out.println(new URI("HTTP://Nerd.dk/").equals(new
URI("http://nerd.dk/")));
vs
System.out.println(new URI("http://nerd.dk/a").equals(new
URI("http://nerd.dk/A")));

--
Andreas

---

Andreas Plesner Jacobsen skrev den 17-02-2008 22:58:
> On 2008-02-17, Thorbjørn Ravn Andersen <thunderaxiom@gmail.com> wrote:
>
>>>>> Men der er vel strengt taget URI'er, der har forskellige
>>>>> strengrepræsentationer men alligevel burde betragtes som ens. Et
>>>> Hvis du ved den slags, skriver du din egen sammenligningskode.
>>> Hvorfor det? URI ved det allerede.
>> Eksempel tak.
>
> System.out.println(new URI("HTTP://Nerd.dk/").equals(new
> URI("http://nerd.dk/")));

Du kunne sagtens have en vhost på Nerd.dk og en anden på nerd.dk

> vs
> System.out.println(new URI("http://nerd.dk/a").equals(new
> URI("http://nerd.dk/A")));

Du kunne sagtens afvikle på en platform hvor filsystemet skelner mellem
store og små bogstaver. Verden er andet end Windows.

--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

On 2008-02-17, Thorbjørn Ravn Andersen <thunderaxiom@gmail.com> wrote:
>>
>>>>>> Men der er vel strengt taget URI'er, der har forskellige
>>>>>> strengrepræsentationer men alligevel burde betragtes som ens. Et
>>>>> Hvis du ved den slags, skriver du din egen sammenligningskode.
>>>> Hvorfor det? URI ved det allerede.
>>> Eksempel tak.
>>
>> System.out.println(new URI("HTTP://Nerd.dk/").equals(new
>> URI("http://nerd.dk/")));
>
> Du kunne sagtens have en vhost på Nerd.dk og en anden på nerd.dk

Ikke hvis jeg ville overholde reglerne for en URL, læs RFC 2616 3.2.3.
Og derudover er der stadig HTTP/http (URI scheme), der netop skal
betragtes som ren lower-case jf RFC 2396 3.1.

>> vs
>> System.out.println(new URI("http://nerd.dk/a").equals(new
>> URI("http://nerd.dk/A")));
>
> Du kunne sagtens afvikle på en platform hvor filsystemet skelner mellem
> store og små bogstaver. Verden er andet end Windows.

Ja. Det var netop pointen, og URI returnerer false i ovenstående
tilfælde (i modsætning til det første eksempel). Noget du ikke kan
emulere med strengsammenligning.

--
Andreas

---

Andreas Plesner Jacobsen wrote:
> On 2008-02-17, Thorbjørn Ravn Andersen <thunderaxiom@gmail.com> wrote:
>>>>>>> Men der er vel strengt taget URI'er, der har forskellige
>>>>>>> strengrepræsentationer men alligevel burde betragtes som ens. Et
>>>>>> Hvis du ved den slags, skriver du din egen sammenligningskode.
>>>>> Hvorfor det? URI ved det allerede.
>>>> Eksempel tak.
>>> System.out.println(new URI("HTTP://Nerd.dk/").equals(new
>>> URI("http://nerd.dk/")));
>> Du kunne sagtens have en vhost på Nerd.dk og en anden på nerd.dk
>
> Ikke hvis jeg ville overholde reglerne for en URL, læs RFC 2616 3.2.3.
> Og derudover er der stadig HTTP/http (URI scheme), der netop skal
> betragtes som ren lower-case jf RFC 2396 3.1.
>
>>> vs
>>> System.out.println(new URI("http://nerd.dk/a").equals(new
>>> URI("http://nerd.dk/A")));
>> Du kunne sagtens afvikle på en platform hvor filsystemet skelner mellem
>> store og små bogstaver. Verden er andet end Windows.
>
> Ja. Det var netop pointen, og URI returnerer false i ovenstående
> tilfælde (i modsætning til det første eksempel). Noget du ikke kan
> emulere med strengsammenligning.

Hvilket efter min mening er et godt argument for ikke at have equals
i URL og URI.

Det er ikke særligt veldefineret hvad "ens" URL'er faktisk er.

Arne

---

On 2008-02-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> Hvilket efter min mening er et godt argument for ikke at have equals
> i URL og URI.
>
> Det er ikke særligt veldefineret hvad "ens" URL'er faktisk er.

Enig. Det er ikke trivielt.

--
Andreas

---

Andreas Plesner Jacobsen skrev den 17-02-2008 23:25:

>>> System.out.println(new URI("HTTP://Nerd.dk/").equals(new
>>> URI("http://nerd.dk/")));
>> Du kunne sagtens have en vhost på Nerd.dk og en anden på nerd.dk
>

> Ikke hvis jeg ville overholde reglerne for en URL, læs RFC 2616 3.2.3.

RFC'ere er ikke regler, og SHOULD er ikke det samme som MUST.

Desuden er det stadig muligt at lave forskelsbehandling på Nerd.dk og
nerd.dk.


> Og derudover er der stadig HTTP/http (URI scheme), der netop skal
> betragtes som ren lower-case jf RFC 2396 3.1.

Det har jeg slet ikke taget stilling til.

>
>>> vs
>>> System.out.println(new URI("http://nerd.dk/a").equals(new
>>> URI("http://nerd.dk/A")));
>> Du kunne sagtens afvikle på en platform hvor filsystemet skelner mellem
>> store og små bogstaver. Verden er andet end Windows.
>
> Ja. Det var netop pointen, og URI returnerer false i ovenstående
> tilfælde (i modsætning til det første eksempel).

Din pointe var så indforstået at jeg åbenbart ikke forstod den. Det
skal hermed beklages.


> Noget du ikke kan emulere med strengsammenligning.

Ville skam ikke tage hele URL'en, men man kan komme langt med fx
getPath().toLowercase() og så er vi ikke langt fra at man alligevel
skriver en sammenligningsmetode hvilket var min oprindelige pointe.


--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Michael Zedeler wrote:
> Andreas Plesner Jacobsen wrote:
>> http://video.google.com/videoplay?docid=9214177555401838409
>
> Avavavavav. Fy for dælen. Hvem her i gruppen er klar over at
> URL-klassens equals-metode er så godt som ubrugelig?

Næppe mange.

Men det symmetriske spørgsmål er jo: hvor mange har nogensinde
brugt URL equals ?

Mit gæt er: endnu færre !

Arne

---

On 2008-02-17, Arne Vajhøj <arne@vajhoej.dk> wrote:

>>> http://video.google.com/videoplay?docid=9214177555401838409
>>
>> Avavavavav. Fy for dælen. Hvem her i gruppen er klar over at
>> URL-klassens equals-metode er så godt som ubrugelig?
>
> Næppe mange.
>
> Men det symmetriske spørgsmål er jo: hvor mange har nogensinde
> brugt URL equals ?
>
> Mit gæt er: endnu færre !

Ja, jeg kan ikke lige komme på en situation hvor jeg har brugt det
(eller brugt URLer i lister), mit største problem er at den bruger tid
og evt skal vente på et timeout på navneopslaget.

--
Andreas

---

Andreas Plesner Jacobsen wrote:
> On 2008-02-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
>>>> http://video.google.com/videoplay?docid=9214177555401838409
>>> Avavavavav. Fy for dælen. Hvem her i gruppen er klar over at
>>> URL-klassens equals-metode er så godt som ubrugelig?
>> Næppe mange.
>>
>> Men det symmetriske spørgsmål er jo: hvor mange har nogensinde
>> brugt URL equals ?
>>
>> Mit gæt er: endnu færre !
>
> Ja, jeg kan ikke lige komme på en situation hvor jeg har brugt det
> (eller brugt URLer i lister), mit største problem er at den bruger tid
> og evt skal vente på et timeout på navneopslaget.

At den også er langsom er da det mindste problem!

I min begrebsverden går grænsen for hvornår en equals er anvendelig der
hvor den ikke længere er deterministisk ift. java-miljøets tilstand.
Hvis et eller andet uden for kan afgøre udfaldet af et kald til equals,
er fanden løs i laksegade. Denne opførsel er så besynderlig at jeg
hurtigt kunne spilde mange dage på debugging før jeg ville finde på at
teste URL.equals().

Mvh. Michael.

---

Arne Vajhøj wrote:
> Michael Zedeler wrote:
>> Andreas Plesner Jacobsen wrote:
>>> http://video.google.com/videoplay?docid=9214177555401838409
>>
>> Avavavavav. Fy for dælen. Hvem her i gruppen er klar over at
>> URL-klassens equals-metode er så godt som ubrugelig?
>
> Næppe mange.
>
> Men det symmetriske spørgsmål er jo: hvor mange har nogensinde
> brugt URL equals ?
>
> Mit gæt er: endnu færre !

Jeg har da brugt klassen en del gange og skal tilstå at jeg ville have
forventet at dens equals ville opføre sig en del pænere. Det er meget
muligt at jeg har brugt den, men kan ikke huske koden specielt godt.

Mvh. Michael.

---

Michael Zedeler wrote:
> Arne Vajhøj wrote:
>> Michael Zedeler wrote:
>>> Andreas Plesner Jacobsen wrote:
>>>> http://video.google.com/videoplay?docid=9214177555401838409
>>>
>>> Avavavavav. Fy for dælen. Hvem her i gruppen er klar over at
>>> URL-klassens equals-metode er så godt som ubrugelig?
>>
>> Næppe mange.
>>
>> Men det symmetriske spørgsmål er jo: hvor mange har nogensinde
>> brugt URL equals ?
>>
>> Mit gæt er: endnu færre !
>
> Jeg har da brugt klassen en del gange og skal tilstå at jeg ville have
> forventet at dens equals ville opføre sig en del pænere. Det er meget
> muligt at jeg har brugt den, men kan ikke huske koden specielt godt.

Jeg har også brugt klassen masser af gange.

Men jeg er ret sikker på at jeg aldrig har brugt dens quals.

Arne

---

Arne Vajhøj <arne@vajhoej.dk> writes:

> Ved load balancing er der vel kun 1 URL, som så distribueres
> til flere boxe.

Og hvis du bruger DNS-baseret load balancing (fx round robin),
så vil URL's equals sige at to *ens* URL'er ikke er equal. ICK!

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

---

On 2008-02-17, Lasse Reichstein Nielsen <lrn@hotpop.com> wrote:
>
>> Ved load balancing er der vel kun 1 URL, som så distribueres
>> til flere boxe.
>
> Og hvis du bruger DNS-baseret load balancing (fx round robin),
> så vil URL's equals sige at to *ens* URL'er ikke er equal. ICK!

Nogle gange. :)

--
Andreas

---

Lasse Reichstein Nielsen wrote:
> Arne Vajhøj <arne@vajhoej.dk> writes:
>> Ved load balancing er der vel kun 1 URL, som så distribueres
>> til flere boxe.
>
> Og hvis du bruger DNS-baseret load balancing (fx round robin),
> så vil URL's equals sige at to *ens* URL'er ikke er equal. ICK!

I teorien ja.

Men mon ikke det lookup ville blive cachet i praksis.

Arne

---

On 2008-02-17, Arne Vajhøj <arne@vajhoej.dk> wrote:

>>> Ved load balancing er der vel kun 1 URL, som så distribueres
>>> til flere boxe.
>>
>> Og hvis du bruger DNS-baseret load balancing (fx round robin),
>> så vil URL's equals sige at to *ens* URL'er ikke er equal. ICK!
>
> I teorien ja.
>
> Men mon ikke det lookup ville blive cachet i praksis.

I praksis vil resolveren modtage et svar med begge hosts i (så længe det
kan være i en enkelt UDP-pakke). Og det burde være det, der bliver
cachet. Så i praksis vil du ikke cache et enkelt svar, nej.

Dette er i øvrigt et krav for at leve op til RFC 1123s krav til
multihoming, som desværre er blevet overhørt af mange.

--
Andreas

---

Andreas Plesner Jacobsen wrote:
> On 2008-02-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
>>>> Ved load balancing er der vel kun 1 URL, som så distribueres
>>>> til flere boxe.
>>> Og hvis du bruger DNS-baseret load balancing (fx round robin),
>>> så vil URL's equals sige at to *ens* URL'er ikke er equal. ICK!
>> I teorien ja.
>>
>> Men mon ikke det lookup ville blive cachet i praksis.
>
> I praksis vil resolveren modtage et svar med begge hosts i (så længe det
> kan være i en enkelt UDP-pakke). Og det burde være det, der bliver
> cachet. Så i praksis vil du ikke cache et enkelt svar, nej.

Hvad udskriver:

import java.net.InetAddress;
import java.util.HashMap;
import java.util.Map;
import java.util.Map.Entry;

public class DNSLookup {
private static final String MS = "www.microsoft.com";
public static void main(String[] args) throws Exception {
Map<String, Integer> m = new HashMap<String, Integer>();
InetAddress[] all = InetAddress.getAllByName(MS);
for(InetAddress one : all) {
m.put(one.getHostAddress(), 0);
}
for(int i = 0; i < 10000; i++) {
String ms = InetAddress.getByName(MS).getHostAddress();
m.put(ms, m.get(ms) + 1);
}
for(Entry<String, Integer> e : m.entrySet()) {
System.out.println(e.getKey() + ": " + e.getValue());
}
}
}

hos dig ?

Arne

---

On 2008-02-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>>>>> Ved load balancing er der vel kun 1 URL, som så distribueres
>>>>> til flere boxe.
>>>> Og hvis du bruger DNS-baseret load balancing (fx round robin),
>>>> så vil URL's equals sige at to *ens* URL'er ikke er equal. ICK!
>>> I teorien ja.
>>>
>>> Men mon ikke det lookup ville blive cachet i praksis.
>>
>> I praksis vil resolveren modtage et svar med begge hosts i (så længe det
>> kan være i en enkelt UDP-pakke). Og det burde være det, der bliver
>> cachet. Så i praksis vil du ikke cache et enkelt svar, nej.
>
> Hvad udskriver:

207.46.19.190: 0
207.46.193.254: 0
207.46.192.254: 10000
207.46.19.254: 0

Hvis jeg reducerer opslagene til 10 stk og sleep()er 11 sekunder imellem
hvert opslag får jeg derimod:

207.46.19.190: 4
207.46.193.254: 3
207.46.192.254: 0
207.46.19.254: 3

Da standard-cachen overlever 10 sekunder.

Og det vil jeg faktisk mene er en bug i InetAddress. Iflg afsnittet om
InetAddress caching står der godt nok at den cacher svaret, men den
burde cache hele svaret og give en tilfældig eller et prioriteret svar
hver gang.

RFC 1123 er desværre ikke helt så klar i spyttet som jeg er:

6.1.3.4 Multihomed Hosts

When the host name-to-address function encounters a host
with multiple addresses, it SHOULD rank or sort the
addresses using knowledge of the immediately connected
network number(s) and any other applicable performance or
history information.

DISCUSSION:
The different addresses of a multihomed host generally
imply different Internet paths, and some paths may be
preferable to others in performance, reliability, or
administrative restrictions. There is no general way
for the domain system to determine the best path. A
recommended approach is to base this decision on local
configuration information set by the system
administrator.

IMPLEMENTATION:
The following scheme has been used successfully:

(a) Incorporate into the host configuration data a
Network-Preference List, that is simply a list of
networks in preferred order. This list may be
empty if there is no preference.

(b) When a host name is mapped into a list of IP
addresses, these addresses should be sorted by
network number, into the same order as the
corresponding networks in the Network-Preference
List. IP addresses whose networks do not appear
in the Network-Preference List should be placed at
the end of the list.

Men mange årtiers unix-baserede resolvere har altså altid leveret
resultaterne i tilfældig rækkefølge, og jeg synes det er ærgeligt at man
har valgt at bryde med dette i Java, men det lader jo til at være "by
design".

Indrømmet, jeg var for hurtig, da jeg udtalte mig om hvordan det virker
i Java, men jeg havde blot ikke forestillet mig at man kunne finde på at
gøre det på denne måde.

--
Andreas

---

On Sun, 17 Feb 2008 21:22:26 +0000 (UTC)
Andreas Plesner Jacobsen <apj@daarligstil.dk> wrote:

>
> Hvorfor det? URI ved det allerede.
>
Lad os for argumentets skyld antage, at vi har viden om, at en række
URL, måske endda til forskellige IP, alle peger til samme sider, da et
site anvender load balancing.

I denne situation ville det da være mest nærliggende, hvis vi
overskriver hashCode og equals, så alle disse URL opfattes som
identiske.

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917
A computer is like air conditioning: it becomes useless when you open
windows.

---

On 2008-02-17, Michael Rasmussen <mir@miras.org> wrote:
>>
>> Hvorfor det? URI ved det allerede.
>>
> Lad os for argumentets skyld antage, at vi har viden om, at en række
> URL, måske endda til forskellige IP, alle peger til samme sider, da et
> site anvender load balancing.
>
> I denne situation ville det da være mest nærliggende, hvis vi
> overskriver hashCode og equals, så alle disse URL opfattes som
> identiske.

Ja. Men det er et helt andet problem du beskriver der. Prøv at læse
tråden igen.

--
Andreas

---

Michael Rasmussen wrote:
> On Sun, 17 Feb 2008 21:22:26 +0000 (UTC)
> Lad os for argumentets skyld antage, at vi har viden om, at en række
> URL, måske endda til forskellige IP, alle peger til samme sider, da et
> site anvender load balancing.

Det du beskriver lyder mere som et mirror site.

Ved load balancing er der vel kun 1 URL, som så distribueres
til flere boxe.

> I denne situation ville det da være mest nærliggende, hvis vi
> overskriver hashCode og equals, så alle disse URL opfattes som
> identiske.

Tja. Det kunne man da. Men jeg tvivler på at man nogensinde vil
have behovet.

Arne

---

On Sun, 17 Feb 2008 21:33:42 +0000 (UTC)
Andreas Plesner Jacobsen <apj@daarligstil.dk> wrote:

>
> Ja. Men det er et helt andet problem du beskriver der. Prøv at læse
> tråden igen.
>
Jeg antog, at du besvarede Thorbjørns indlæg:
"Hvis du ved den slags, skriver du din egen sammenligningskode."

Hvilket jeg så reflekterede over.

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917
A computer is like air conditioning: it becomes useless when you open
windows.

---

On 2008-02-17, Michael Rasmussen <mir@miras.org> wrote:
>>
>> Ja. Men det er et helt andet problem du beskriver der. Prøv at læse
>> tråden igen.
>>
> Jeg antog, at du besvarede Thorbjørns indlæg:
> "Hvis du ved den slags, skriver du din egen sammenligningskode."

Jeg betragter det du beskriver som en optimering, mens de andre
problemer handlede om korrekt opførsel.

--
Andreas

---

Andreas Plesner Jacobsen wrote:
> On 2008-02-17, Michael Rasmussen <mir@miras.org> wrote:
>>> Ja. Men det er et helt andet problem du beskriver der. Prøv at læse
>>> tråden igen.
>>>
>> Jeg antog, at du besvarede Thorbjørns indlæg:
>> "Hvis du ved den slags, skriver du din egen sammenligningskode."
>
> Jeg betragter det du beskriver som en optimering, mens de andre
> problemer handlede om korrekt opførsel.

Hvis han definerer korrekt opførsel som at de 2 URL'er der
fører til mirror'ed ressource er ens, så ...

Arne