XMLHttpRequest für Firefox

[Marco]

Hallo,

ich habe für die XMLHttpRequest Funktion ein einfaches Script in der Wikipedia gefunden.
Das funktioniert mit MS IE ganz gut, nur bei Firefox bekomme ich keinen Wert zurück.
Wenn ich aber anstelle "Inhalt = (xmlHttp.responseText);" "alert(xmlHttp.responseText);" notiere, dann bekomme ich auch bei Firefox den Dateiinhalt zurück.
Was kann ich anstellen, oder ändern, damit ich auch bei Mozilla die Daten zurückbekomme.

function LadeDatei(Dateiname)
{
  var xmlHttp = false;

// Internet Explorer
  try
  {
    xmlHttp  = new ActiveXObject("Msxml2.XMLHTTP");
  }
  catch(e)
  {
    try
    {
      xmlHttp  = new ActiveXObject("Microsoft.XMLHTTP");
    }
    catch(e)
    {
      xmlHttp  = false;
    }
  }
  // Mozilla, Opera und Safari
  if (!xmlHttp  && typeof XMLHttpRequest != 'undefined')
  {
    xmlHttp = new XMLHttpRequest();
  }
  if (xmlHttp)
  {
    xmlHttp.open('GET', Dateiname, true);
    xmlHttp.onreadystatechange = function ()
    {
      if (xmlHttp.readyState == 4)
      {
        Inhalt = (xmlHttp.responseText);
      }
    };
    xmlHttp.send(null);
  }
  return Inhalt;
}

Danke schön im Voraus

Marco

[Marc Reichelt]

Hallo Marco,

ich habe für die XMLHttpRequest Funktion ein einfaches Script in der Wikipedia gefunden.
Das funktioniert mit MS IE ganz gut, nur bei Firefox bekomme ich keinen Wert zurück.
Wenn ich aber anstelle "Inhalt = (xmlHttp.responseText);" "alert(xmlHttp.responseText);" notiere, dann bekomme ich auch bei Firefox den Dateiinhalt zurück.
Was kann ich anstellen, oder ändern, damit ich auch bei Mozilla die Daten zurückbekomme.

Ich denke, ich habe dein Problem:

  
if (xmlHttp.readyState == 4)  
{  
  Inhalt = (xmlHttp.responseText);  
}  

Die Variable "Inhalt" wird im if-Block angelegt. Ergo ist dies der Scope der Variablen "Inhalt", das bedeutet, dass die Variable danach nicht mehr zur Verfügung steht (also z.B. zum Auslesen).

Erzeuge nach der Zeile mit "var xmlHttp = false;" noch eine Zeile mit "var Inhalt;".
Es wäre schön, wenn du Bescheid gibst ob es funktioniert, da ich das jetzt nicht getestet habe.
Im Übrigen lässt sich dieser Fehler eventuell in der JavaScript-Konsole von Firefox finden.

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[Christian Kruse]

你好 Marc,

Die Variable "Inhalt" wird im if-Block angelegt. Ergo ist dies der
Scope der Variablen "Inhalt", das bedeutet, dass die Variable danach
nicht mehr zur Verfügung steht (also z.B. zum Auslesen).

Gute Idee, aber leider nicht richtig: eine Variable erhält in JS nur dann
einen Block-Scope, wenn bei ihrer ersten Verwendung das Schlüsselwort var
vorran gestellt wird. Ansonsten ist sie global. Das führt bei konsequenter
Nicht-Verwendung von var zu netten Seiteneffekten bei z. B. verschachtelten
Schleifen:

  
function cnt2() {  
  for(;i<10;++i);  
}  
  
function cnt1() {  
  for(i=0;i<10;++i) {  
    alert("called with i=" + i);  
    cnt2();  
  }  
}  

Rein logisch müsste hier 10x die Schleife durchlaufen werden. Jedoch bricht
sie aufgrund des Aufrufes von cnt2() bereits nach dem ersten mal ab.

再见,
 克里斯蒂安

[Christoph Zurnieden]

Hi,

Wenn ich aber anstelle "Inhalt = (xmlHttp.responseText);" "alert(xmlHttp.responseText);" notiere, dann bekomme ich auch bei Firefox den Dateiinhalt zurück.

Und wenn Du es anstelle von "Inhalt = (xmlHttp.responseText);" mit "Inhalt = xmlHttp.responseText;" versuchst?

Erklaerung erst, wenn's daran gelegen hat und nicht am Scope, wie Marc vermutet.

so short

Christoph Zurnieden

PS: die Fehlermeldungen beim Posten sind immer noch recht schweigsam, wie ich feststellen muss ;-)

[Struppi]

function LadeDatei(Dateiname)
{
  var xmlHttp = false;

// Internet Explorer
  try
  {
    xmlHttp  = new ActiveXObject("Msxml2.XMLHTTP");
  }
  catch(e)
  {
    try
    {
      xmlHttp  = new ActiveXObject("Microsoft.XMLHTTP");
    }
    catch(e)
    {
      xmlHttp  = false;
    }
  }
  // Mozilla, Opera und Safari
  if (!xmlHttp  && typeof XMLHttpRequest != 'undefined')
  {
    xmlHttp = new XMLHttpRequest();
  }
  if (xmlHttp)
  {
    xmlHttp.open('GET', Dateiname, true);
    xmlHttp.onreadystatechange = function ()
    {
      if (xmlHttp.readyState == 4)
      {
        Inhalt = (xmlHttp.responseText);
      }
    };
    xmlHttp.send(null);
  }
  return Inhalt;
}

du hast den Event onreadystatechange nicht verstanden. Inhalt wird erst gesetzt, wenn die Datei gelesen wurde, du versuchtst aber den Wert schon zurück zu geben wenn die Funktion mit grosser wahrscheinlichkeit noch gar nicht ausgelöst wurde.

D.h. return IOnhalt geht in die Hose, du kannst erst auf Inhalt zugreifen nachdem die Funktion nach dem Event onreadystatechange aufgerufen wurde.

Struppi.

[Marco]

Hallo,

Danke erstmal.

"xmlHttp.onreadystatechange = function ()"

Jetzt habe ich es verstanden. Erst wenn geladen, wird die Funktion abgearbeitet.
Von dort aus muss dann die Rückgabe, bzw. der Aufruf der Function erfolgen, die mit dem Dateiinhalt arbeiten möchte.

Nochmals, Danke

Marco

[Christoph Zurnieden]

Hi,

du hast den Event onreadystatechange nicht verstanden. Inhalt wird erst gesetzt, wenn die Datei gelesen wurde, du versuchtst aber den Wert schon zurück zu geben wenn die Funktion mit grosser wahrscheinlichkeit noch gar nicht ausgelöst wurde.

Ja, da hatte ich mich wohl auch von der anonymen Funktion auf's Glatteis fuehren lassen, ich ging davon aus, das die ausreichend trennt. Nuetzt aber natuerlich sowieso nix, denn es wurde ja auch noch ausdruecklich asynchrone Abfrage bestellt.

Da wollte ich es aber nun ein wenig ordentlich machen und musste feststellen, das ich auf eine XML-Anfrage einen 304 zurueckbekomme, da der Opera (8.5) eine entsprechende Anfrage stellt (aber noch nicht geprueft, nur eine Vermutung).
Mache ich da 'was falsch?
(Basissystem ist ein Debian 3.0r2 mit Update vom 14.02.2004)
Aufrufende Datei:

  
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">  
<html>  
<head><title>Hu?</title>  
<script type="text/javascript">  
var xmlHttp = false;  
  
function showHit(_Hit){  
  var temp1;  
  var temp2;  
  var Hit = _Hit;  
  
  temp1 = document.createElement("br");  
  temp2 = document.createTextNode(Hit);  
  document.getElementById("hitlist").appendChild(temp1);  
  document.getElementById("hitlist").appendChild(temp2);  
}  
function clearHits(){  
  var arnold = document.getElementById("hitlist");  
  var adam   = arnold.cloneNode(false);  
  
  arnold.parentNode.replaceChild(adam,arnold);  
}  
function procData(){  
      response  = xmlHttp.responseXML;  
      vn   = response.getElementsByName("vorname")[0].firstChild.data;  
      nn   = response.getElementsByName("nachname")[0].firstChild.data;  
      alert(nn);  
      showHit("Vorname:" + vn);  
      showHit("Nachname:" + nn);  
}  
function procResponse(){  
  if(xmlHttp.readyState == 4){//alert(xmlHttp.status);  
    if(xmlHttp.status == 200){  
      procData();  
    }  
  }  
}  
function getData(){  
  //var xmlHttp = false;  
  
  // Internet Explorer  
  try{  
    xmlHttp  = new ActiveXObject("Msxml2.XMLHTTP");  
  }  
  catch(e){  
    try{  
      xmlHttp  = new ActiveXObject("Microsoft.XMLHTTP");  
    }  
    catch(e){  
      xmlHttp  = false;  
    }  
  }  
  // Mozilla, Opera und Safari  
  if (!xmlHttp  && typeof XMLHttpRequest != 'undefined'){  
    xmlHttp = new XMLHttpRequest();  
  }  
  if (xmlHttp){  
    xmlHttp.open('GET', "data.xml", true);  
    xmlHttp.onreadystatechange = procResponse;  
    xmlHttp.send(null);  
  }  
}  
</script>  
</head>  
<body>  
<form action="" onsubmit="getData();return false;">  
Push button:<br>  
<input type="button" value="push me!" onclick="getData();">  
</form>  
<div id="hitlist"></div>  
</body>  
</html>  
  

Daten-XML:

  
<?xml version="1.0" standalone="yes"?>  
<!DOCTYPE data [  
<!ELEMENT data (row)+>  
<!ATTLIST data  
  name     CDATA   #IMPLIED  
  atime    CDATA   #IMPLIED  
  ctime    CDATA   #IMPLIED  
  mtime    CDATA   #REQUIRED  

>  

<!ELEMENT row (cell)+>  
<!ATTLIST row  
  id       ID      #REQUIRED  
  name     CDATA   #IMPLIED  
  atime    CDATA   #IMPLIED  
  ctime    CDATA   #IMPLIED  
  mtime    CDATA   #IMPLIED  

>  

<!ELEMENT cell (#PCDATA)>  
<!ATTLIST cell  
  name     CDATA   #IMPLIED  
  atime    CDATA   #IMPLIED  
  ctime    CDATA   #IMPLIED  
  mtime    CDATA   #IMPLIED  

>  

<data mtime="Fri, 14 Oct 2005 15:43:54 +0200">  
<row id="r001">  
<cell name="vorname">Otto</cell>  
<cell name="nachname">Meier</cell>  
</row>  
<row id="r002">  
<cell name="vorname">Hans</cell>  
<cell name="nachname">Schulze</cell>  
</row>  
</data>  

Habe ich da jetzt irgendeinen bloeden Haken eingebaut (ist ja schon ungefaehr zwei Jahre her, das ich das letzte Mal mit XMLHttpRequest gearbeitet habe), ist das der Opera oder ein Bug im Apachen oder ... ?

so short

Christoph Zurnieden

[molily]

Hallo,

Da wollte ich es aber nun ein wenig ordentlich machen und musste feststellen, das ich auf eine XML-Anfrage einen 304 zurueckbekomme, da der Opera (8.5) eine entsprechende Anfrage stellt (aber noch nicht geprueft, nur eine Vermutung).
Mache ich da 'was falsch?

Nein, wieso auch? Du forderst eine Ressource an, die der Browser schon im Cache hat. Opera schickt selbstverständlich einen Conditional GET, wenn der Server brav beim ersten Request einen Last-Modified- oder ETag-Header schickt. Du hast zudem wahrscheinlich keine Header gesendet, die das Cachen verhindern.

Habe ich da jetzt irgendeinen bloeden Haken eingebaut (ist ja schon ungefaehr zwei Jahre her, das ich das letzte Mal mit XMLHttpRequest gearbeitet habe), ist das der Opera oder ein Bug im Apachen oder ... ?

Warum soll es ein Bug sein. Sowohl Opera als auch Apache verhalten sich korrekt. Ich sehe das Problem nicht. Man muss eben damit rechnen, dass die status-Eigenschaft auch 304 haben kann, wenn es sich um eine (i.d.R. statische) Ressource auf dem Server handelt, welche mit Last-Modified-Angabe und/oder ETag ausgeliefert wird.

Mathias

[Christoph Zurnieden]

Hi,

Da wollte ich es aber nun ein wenig ordentlich machen und musste feststellen, das ich auf eine XML-Anfrage einen 304 zurueckbekomme, da der Opera (8.5) eine entsprechende Anfrage stellt (aber noch nicht geprueft, nur eine Vermutung).
Mache ich da 'was falsch?

Nein, wieso auch? Du forderst eine Ressource an, die der Browser schon im Cache hat.

Soweit ist das ja auch korrekt. Allerdings dachte ich, das eine "reload page" Anweisung (das Recyclingsymbol im Opera) dies ueberschreibt.

Opera schickt selbstverständlich einen Conditional GET, wenn der Server brav beim ersten Request einen Last-Modified- oder ETag-Header schickt.

Das habe ich aber nicht verlangt sondern sogar ausdruecklich dsa Gegenteil -- warum macht Opera das, ist das Vorschrift?

Du hast zudem wahrscheinlich keine Header gesendet, die das Cachen verhindern.

Nein, warum auch. Ich dachte ja, das ich dem Browser gesagt hatte, das er die Seite _neu_ holen solle und _nicht_ aus dem Cache. Wie soll ich eigentlich an den Cache rankommen von XMLHttpRequest aus?

Habe ich da jetzt irgendeinen bloeden Haken eingebaut (ist ja schon ungefaehr zwei Jahre her, das ich das letzte Mal mit XMLHttpRequest gearbeitet habe), ist das der Opera oder ein Bug im Apachen oder ... ?

Warum soll es ein Bug sein.

Du meinst es waere ein Bedienungsfehler meinerseits?
Wie kann ich denn nun dem Opera beibiegen, das er sich gefaelligst an die Anweisungen seines Herrn und Meisters halten soll?

Sowohl Opera als auch Apache verhalten sich korrekt. Ich sehe das Problem nicht. Man muss eben damit rechnen, dass die status-Eigenschaft auch 304 haben kann, wenn es sich um eine (i.d.R. statische) Ressource auf dem Server handelt, welche mit Last-Modified-Angabe und/oder ETag ausgeliefert wird.

Ich rechne ja auch damit, warum aber rechnet Opera nicht damit?
Es kann sich aber auch um einen Bug im Apachen/Fehlkonfiguration der http.conf (default, ich habe nichts daran geaendert) handeln, denn eine Aenderung der Datei data.xml auf dem Server (Leerzeichen hinzugefuegt) ergab keine Aenderung des Verhaltens. Ja, Last-Modified und ETag wurden vom Apachen ordnungsgemaess angepasst. Alles _sehr_ merkwuerdig!

Ich nehme mal an, Du konntest das Verhalten nicht nachvollziehen?

so short

Christoph Zurnieden

[molily]

Hallo,

Du forderst eine Ressource an, die der Browser schon im Cache hat.

Soweit ist das ja auch korrekt. Allerdings dachte ich, das eine "reload page" Anweisung (das Recyclingsymbol im Opera) dies ueberschreibt.

Korrekt.
Aber was hat das mit dem XMLHttpRequest zu tun, den diese Seite im Hintergrund absendet?

Opera schickt selbstverständlich einen Conditional GET, wenn der Server brav beim ersten Request einen Last-Modified- oder ETag-Header schickt.

Das habe ich aber nicht verlangt

Du meinst, du hast selbst keinen If-Modified-Since oder If-None-Match mit setRequestHeader gesetzt? Gut, in diesem Sinne hast du es tatsächlich nicht ausdrücklich verlangt, aber ...

sondern sogar ausdruecklich dsa Gegenteil

... aber das Gegenteil hast du nicht ausdrücklich verlangt (wie auch).

warum macht Opera das, ist das Vorschrift?

Nein, aber Opera nutzt ein Feature von HTTP aus und ich finde es sehr logisch. Opera speichert Ressourcen (ohne das Caching verhindernde Header, mit Last-Modified oder ETag) zwischen und bei einer erneuten Abfrage wird erst einmal ein Conditional GET gesendet.

Du hast zudem wahrscheinlich keine Header gesendet, die das Cachen verhindern.

Nein, warum auch. Ich dachte ja, das ich dem Browser gesagt hatte, das er die Seite _neu_ holen solle

Nein, denn das geht im Falle von XMLHttpRequest nicht (es sei denn, man ändert z.B. den Query String, indem man z.B. den aktuellen Unix-Timesstamp an die URL anhängt).
Vielleicht funktioniert das Überschreiben der Header If-Modified-Since und If-None-Match.

und _nicht_ aus dem Cache. Wie soll ich eigentlich an den Cache rankommen von XMLHttpRequest aus?
Wie kann ich denn nun dem Opera beibiegen, das er sich gefaelligst an die Anweisungen seines Herrn und Meisters halten soll?

Anders gefragt: Inwiefern gereicht einem Operas Verhalten zum Nachteil? Der Server sendet eine Ressource z.B. mit einem gewissen Entity-Tag.
Handelt es sich um eine »statische« Datei auf dem Server, so berechnet Apache den ETag anhand der Inode-Nummer, der letzten Änderung und der Dateigröße. In der Regel bezeichnet der ETag damit eindeutig eine Ressource. Ein Conditional GET ist in dieser Hinsicht unproblematisch. Wenn man mit XMLHttpRequest eine Datei vom Server beziehen will, bekommt man immer die aktuellste Version.
Handelt es sich um eine dynamisch generierte Ressource, so wird i.d.R. weder ETag noch Last-Modified gesendet. Es obliegt der CGI-Logik, solche Header zu senden. Es kann z.B. mit einer performanten Datenbankabfrage in Erfahrung gebracht werden, wann sich die fraglichen Daten geändert haben. Daraus bildet man einen sinnigen ETag. Falls der Request eine Bedingung enthält, wird diese überprüft. Erst wenn sich die Daten geändert haben, fragt man sie komplett ab und generiert eine Ressource. Auch in diesem Fall verläuft das Abfragen über XMLHttpRequest problemlos.

Es kann sich aber auch um einen Bug im Apachen/Fehlkonfiguration der http.conf (default, ich habe nichts daran geaendert) handeln, denn eine Aenderung der Datei data.xml auf dem Server (Leerzeichen hinzugefuegt) ergab keine Aenderung des Verhaltens. Ja, Last-Modified und ETag wurden vom Apachen ordnungsgemaess angepasst. Alles _sehr_ merkwuerdig!

Wie meinst du das - du änderst die Datei, Opera sendet einen Conditional GET und Apache antwortet mit 304, aber anderem ETag? Wie soll das funktionieren?

Ich nehme mal an, Du konntest das Verhalten nicht nachvollziehen?

Möglich, dass ich dich nicht verstehe.
Wenn ich deine Beispieldokumente nehme, auf meinen lokalen Apache lege und das HTML-Dokument aufrufe, wird der XMLHttpRequest ganz normal gestartet. Der Cache ist leer, Opera sendet den Request und bekommt das XML-Dokument mit 200 zurück. Alle folgenden Requests werden mit 304 beantwortet, das Dokument steht aber trotzdem in xmlResponse zur Verfügung.
Was darüber hinaus das JavaScript angeht, so hatte ich nicht weiter getestet. Du versuchst allerdings, die DOM-HTML-Methode getElementsByName in einem generischen XML-Dokument anzuwenden, wo nur DOM Core möglich ist. Daher gibt es in der Zeile vn = response.getElementsByName("vorname")[0].firstChild.data; einen JavaScript-Fehler. Der Inhalt des XML-Dokuments wird somit nicht korrekt ausgelesen und im HTML-Dokument angezeigt.

Mathias

[Christoph Zurnieden]

Hi,

Du forderst eine Ressource an, die der Browser schon im Cache hat.

Soweit ist das ja auch korrekt. Allerdings dachte ich, das eine "reload page" Anweisung (das Recyclingsymbol im Opera) dies ueberschreibt.

Korrekt.
Aber was hat das mit dem XMLHttpRequest zu tun, den diese Seite im Hintergrund absendet?

Ich haette das vererbt.

sondern sogar ausdruecklich das Gegenteil

... aber das Gegenteil hast du nicht ausdrücklich verlangt (wie auch).

Doch, ich habe XMLHttpRequest ein "GET" mitgegeben, und sonst nichts.

warum macht Opera das, ist das Vorschrift?

Nein, aber Opera nutzt ein Feature von HTTP aus und ich finde es sehr logisch. Opera speichert Ressourcen (ohne das Caching verhindernde Header, mit Last-Modified oder ETag) zwischen und bei einer erneuten Abfrage wird erst einmal ein Conditional GET gesendet.

Ich bekomme also nicht, was ich will, sondern das, was Opera meint, das ich moechte?
Ja, wofuer halte ich denn von Microsoftsoftware so fleissig Abstand? ;-)

Wie kann ich denn nun dem Opera beibiegen, das er sich gefaelligst an die Anweisungen seines Herrn und Meisters halten soll?

Anders gefragt: Inwiefern gereicht einem Operas Verhalten zum Nachteil?

Ich weiss nicht, obe es der Allgemeinheit zumn Nachteil gereicht, mir reicht es schon, das es mir im Wege steht.

Ein Conditional GET ist in dieser Hinsicht unproblematisch. Wenn man mit XMLHttpRequest eine Datei vom Server beziehen will, bekommt man immer die aktuellste Version.

Auf die Gefahr hin, mich zu wiederholen: ich habe das nicht bestellt.

Auch in diesem Fall verläuft das Abfragen über XMLHttpRequest problemlos.

Nicht so ganz, wenn man responeXML() benutzt und davon ausgeht, mit DOM keine Probleme zu haben. Ich habe gerade 2 Stunden verplempert, bis ich darauf kam, das da kaum mehr als ein getElementsByTagName() funktioniert. Wenn ich wuesste wo ich nachschauen kann, waere ich versucht, nach einer Moeglichkeit suchen in einen Baum zu parsen (gibt's mindestens bei IE, Konqueror und Mozilla). Kurze Suche auf Opera.com ergab nicht sehr viel, eine intensive Suche mag erfolgreicher sein.

Wie meinst du das - du änderst die Datei, Opera sendet einen Conditional GET und Apache antwortet mit 304, aber anderem ETag? Wie soll das funktionieren?

Nein, war wohl eine Fehlbeobachtung, konnte ich zumindest nicht wiederholen.
Aber etwas anderes konnte ich beobachten: je nach Cacheeinstellung (die habe ich endlich gefunden, wenn auch nicht verstanden, aber daran scheint's wohlgelegen zu haben) bekomme ich wohl einen 200er zurueck, aber nicht die aktuelle Seite. Ich hatte die interne DTD entfernt (sowas mag Opera auch nicht) und responseTExt hat sie noch mitgeliefert. Das war sogar wiederholbar.

Was darüber hinaus das JavaScript angeht, so hatte ich nicht weiter getestet. Du versuchst allerdings, die DOM-HTML-Methode getElementsByName in einem generischen XML-Dokument anzuwenden, wo nur DOM Core möglich ist.

Das sowas nicht funktioniert habe ich mittlerweile auch festgestellt, aber das es in XML verboten ist, war mir neu. Warum ueberhaupt? Wo ist das dokumentiert? Kann man da irgendwo mehr drueber lesen?

so short

Christoph Zurnieden

[Tim Tepaße]

Hallo Christoph,

Doch, ich habe XMLHttpRequest ein "GET" mitgegeben, und sonst nichts.

Nebenbei gesagt: Ich halte Operas Verhalten hier für logisch.

die DOM-HTML-Methode getElementsByName
Das sowas nicht funktioniert habe ich mittlerweile auch festgestellt, aber das es in XML verboten ist, war mir neu. Warum ueberhaupt? Wo ist das dokumentiert? Kann man da irgendwo mehr drueber lesen?

Im Zweifelsfall im entsprechenden Standard die Definition von getElementsByName als Methode des Interfaces HTMLDocument. In dem in DOM 2 Core definierten Interface Interface Document gibt es diese Methode nicht, schließlich bezieht sie sich nur auf HTML-Dokumente.

Der Hintergrund sollte einem bei etwas Vertrautheit mit XML auch klar sein. Außer den querverweisenden Attributtypen definiert der XML-Standard eigentlich nur zwei vordefinierte Attributtypen von Belang, CDATA („String“) und ID (und in Zukunft gibt es wohl xml:id). Weitere Attributtypen gibt es nicht, auch keiner für die Werte von name-Attributen. Die Methode getElementsByName() wird nur im HTML-Kontext auf Elemente mit name-Attribute wirksam, auch wenn dort die name-Attribute vom Typ CDATA sind. Das hatte sich eben mit dem für HTML-Kontext gedachten DOM Level 1 Standard so eingeführt, die generischeren DOM Level 2 Standards sollen dann universaler sein.

Und können deswegen getElementsByName() nicht haben. Weil sie dann ebenso für mein XML 1.1 Dokument mit dem Fragment <sketch heinzelmännchen="ede"> dann bitte ebenso eine Methode getElementsByHeinzelmaennchen() vorhalten sollten, wenn sie gerecht sein wollen.

Nebenbei: In SELFHTML ist der Unterschied naturgemäß nicht so stark herausgearbeitet, trotzdem steht selbst dort: „Die Methode getElementsByName() regelt lediglich den Zugriff auf HTML-Elemente.“ Ja, das könnte klarer formuliert sein, allerdings geschieht das eher in der Form einer für SELFHTML 9 geplanten Umstrukturierung des JS/DOM-Kapitels.

Tim

[Christian Kruse]

你好 Tim,

Doch, ich habe XMLHttpRequest ein "GET" mitgegeben, und sonst nichts.

Nebenbei gesagt: Ich halte Operas Verhalten hier für logisch.

Ich möchte im JS ja irgendwie an die Daten kommen, deshalb mache ich den
Request. Wenn mir da ein Cache von einer vergangenen Session reinhaut ist
das nicht so prickelnd; vor allem weil ich noch keine Methode gefunden habe,
den Conditional GET zu unterdrücken. Ich musste wirklich auf
&unique=<timestamp> ausweichen, um an die Daten zu kommen. Keine schöne
Lösung.

再见,
 克里斯蒂安

[molily]

Hallo,

Ich möchte im JS ja irgendwie an die Daten kommen, deshalb mache ich den Request. Wenn mir da ein Cache von einer vergangenen Session reinhaut ist das nicht so prickelnd

Anscheinend vermischt du zwei Sachen. Ich redete über einen Conditional GET, den Opera sendet, falls der Server ETag oder Last-Modified auf den ersten Request geantwortet hat. Darin sehe ich, wenn auf der Serverseite nicht absichtlich Unsinn veranstaltet wird, wie in https://forum.selfhtml.org/?t=116872&m=748770 ausgeführt kein Problem. Man bekommt immer die aktuellen Daten und falls der XMLHttpRequest ein CGI-Programm auf dem Server ausführen soll, wird dieses in jedem Fall korrekt ausgeführt.

Was du wahrscheinlich meinst (vielleicht meinte auch Christoph dies): Wenn in den Opera-Einstellungen unter »Check documents« nicht »Always« steht bzw. eine entsprechend geringe Zeitspanne, dann führt Opera *gar keinen* (also nicht einmal einen konditionalen) Request zum Server durch, sondern entnimmt die Ressource direkt aus dem Festplatten-Cache. In dem Fall ist man gearscht, weil der Server vom XMLHttpRequest nichts mitbekommt. Deshalb ist »Always« auch m.E. die einzig sinnige Einstellung.

vor allem weil ich noch keine Methode gefunden habe, den Conditional GET zu unterdrücken.

Das Conditional GET ist kein Problem, du meinst wohl eher, du hast keine Methode gefunden, zu unterdrücken, dass Opera bei entsprechender Einstellung aggressiv zwischenspeichert und somit überhaupt keinen Request sendet.
Da kann man wirklich nur individuell seine Cache-Einstellungen ändern, wenn HTTP-Header, die das Cachen verhindern sollen, auf Opera keinen Eindruck machen.

Ich musste wirklich auf &unique=<timestamp> ausweichen, um an die Daten zu kommen.

Ja, das ist der Ausweg zur Umgehung des Cache-Problems. Wenn hingegen der Conditional GET Schwierigkeiten machen sollte, sollte man einfach den Server/die CGI-Logik dazu bringen, sinnvolle oder keine Last-Modified- und ETag-Header zu senden. Das machst du ja beim Cforum z.B. beim Auf-/Zuklappen der Threads, lediglich &unique=... durchkreuzt dies zur Behebung des Cache-Problems.

Mathias

[Christian Kruse]

你好 molily,

Ich möchte im JS ja irgendwie an die Daten kommen, deshalb mache ich
den Request. Wenn mir da ein Cache von einer vergangenen Session
reinhaut ist das nicht so prickelnd

Anscheinend vermischt du zwei Sachen. Ich redete über einen Conditional
GET, den Opera sendet, falls der Server ETag oder Last-Modified auf den
ersten Request geantwortet hat. Darin sehe ich, wenn auf der Serverseite
nicht absichtlich Unsinn veranstaltet wird, wie in
https://forum.selfhtml.org/?t=116872&m=748770 ausgeführt kein
Problem. Man bekommt immer die aktuellen Daten und falls der
XMLHttpRequest ein CGI-Programm auf dem Server ausführen soll, wird
dieses in jedem Fall korrekt ausgeführt.

Wo soll ich denn die Daten herbekommen? Sie sind in Operas Cache – schön,
ich will sie aber verwenden können, im Cache helfen sie mir wenig. Bei
einem 304-Response ist responseText leer.

Was du wahrscheinlich meinst (vielleicht meinte auch Christoph dies):
Wenn in den Opera-Einstellungen unter »Check documents« nicht »Always«
steht bzw. eine entsprechend geringe Zeitspanne, dann führt Opera *gar
keinen* (also nicht einmal einen konditionalen) Request zum Server durch,
sondern entnimmt die Ressource direkt aus dem Festplatten-Cache.

Wenn er mir die Ressource zur Verfügung stellen würde, wäre mir das egal.
Aber ich komme effektiv nicht an die Daten.

Ich musste wirklich auf &unique=<timestamp> ausweichen, um an die Daten
zu kommen.

Ja, das ist der Ausweg zur Umgehung des Cache-Problems. Wenn hingegen der
Conditional GET Schwierigkeiten machen sollte, sollte man einfach den
Server/die CGI-Logik dazu bringen, sinnvolle oder keine Last-Modified-
und ETag-Header zu senden.

Meine Server-Logik sendet vollständig richtige Last-Modified-Header und
schickt einen 304, wenn es die Situation zulässt. Aber anstatt das Opera
die Daten aus dem Cache in den responseText oder ein ähnliches Attribut
setzt, sind sie einfach nicht vorhanden. Gut, man könnte jetzt
argumentieren, dass man dann in JS einen eigenen Cache implementieren
müsse. Halte ich war nicht für sinnvoll, aber es sprechen auch technische
Dinge dagegen: sobald man einen Reload gemacht hat, ist der Cache
dahingeschieden. Ich komme also nicht mehr an die Daten, um sie eventuell
weiterzuverwenden.

Das machst du ja beim Cforum z.B. beim Auf-/Zuklappen der Threads,
lediglich &unique=... durchkreuzt dies zur Behebung des Cache-Problems.

Eben das ist eine der Situationen, in denen ich gern verhindern würde, dass
ein Conditional GET gesendet wird, damit ich an die Daten komme.

再见,
 克里斯蒂安

[molily]

Hallo,

Wo soll ich denn die Daten herbekommen? Sie sind in Operas Cache – schön,
ich will sie aber verwenden können, im Cache helfen sie mir wenig. Bei
einem 304-Response ist responseText leer.

Kann ich nicht bestätigen. responseText ist ordnungsgemäß gefüllt und responseXML enthält das DOMDocument, falls es sich um eine XML-Antwort handelt. Opera 8.5.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">  
<html><head><title>Hu?</title>  
<script type="text/javascript">  
[code lang=javascript]var xmlHttp = false;  
function procData (){  
 alert(xmlHttp.responseXML.getElementsByTagName("cell").length);  
 alert(xmlHttp.responseText);  
}  
function getData (){  
 xmlHttp = new XMLHttpRequest();  
 xmlHttp.open("GET", "data.txt", true); // bzw. data.xml  
 xmlHttp.onload = procData;  
 xmlHttp.send(null);  
}

</script>
</head>
<body>
<input type="button" value="starten" onclick="getData()">
</body>
</html>[/code]

In data.txt steht einfach »blub«.

192.168.2.101 - - [17/Oct/2005:12:57:01 +0200] "GET /js-test-xmlhttprequest.html HTTP/1.1" 200 527 "-" "Opera/8.5 (X11; Linux i686; U; en)"
192.168.2.101 - - [17/Oct/2005:12:57:03 +0200] "GET /data.txt HTTP/1.1" 200 4 "-" "Opera/8.5 (X11; Linux i686; U; en)"
192.168.2.101 - - [17/Oct/2005:12:57:17 +0200] "GET /data.txt HTTP/1.1" 304 - "-" "Opera/8.5 (X11; Linux i686; U; en)"
192.168.2.101 - - [17/Oct/2005:12:57:20 +0200] "GET /data.txt HTTP/1.1" 304 - "-" "Opera/8.5 (X11; Linux i686; U; en)"
usw.

Ich bekomme immer »0« und »blub« in den alerts.

War übrigens »Check other«, nicht »Check documents«. Das auf »Always« zu stellen, ist schon doof, weil dann auch immer Conditional GETs für Stylesheets gesendet werden. I.d.R. habe ich das auf »Never« stehen.

Mathias

[Christian Kruse]

你好 molily,

Kann ich nicht bestätigen. responseText ist ordnungsgemäß gefüllt und
responseXML enthält das DOMDocument, falls es sich um eine XML-Antwort
handelt. Opera 8.5.

Hm. Ja. Du hast recht. Seltsam… ich hatte das anders in Erinnerung. Gut zu
wissen, ein Problem weniger ;)

再见,
 克里斯蒂安

[Christoph Zurnieden]

Hi,

Doch, ich habe XMLHttpRequest ein "GET" mitgegeben, und sonst nichts.

Nebenbei gesagt: Ich halte Operas Verhalten hier für logisch.

Mehrheitsfaehig vielleicht, aber nicht logisch.

Aber Spitzfindigkeiten mal beiseite: mit einer ordentlichen Dokumentation waere das alles kein Problem gewesen. Und mit "alles" meine ich wirklich alle meine aufgefuehrten Probleme. Naja, gut, mal meine eigene Bloedheit ausgenommen :-)

Im Zweifelsfall im entsprechenden Standard

Jaja, gib's mir ruhig, ist ja zu Recht :-)

Ich muesste es zwar noch sorgfaeltig testen um es hieb- und stichfest zu machen, aber das erlaubte getElementById() (bei mir zum Testen beliebt, da es nur ein Element zuruekgibt, das spart den Aerger mit dem Schleifchenbinden) funktioniert wohl nicht.

die generischeren DOM Level 2 Standards sollen dann universaler sein.
Und können deswegen getElementsByName() nicht haben. Weil sie dann ebenso für mein XML 1.1 Dokument mit dem Fragment <sketch heinzelmännchen="ede"> dann bitte ebenso eine Methode getElementsByHeinzelmaennchen() vorhalten sollten, wenn sie gerecht sein wollen.

Was waere dann mit einem getElementsByAttribute("Heinzelmaennchen")?

Nebenbei: In SELFHTML ist der Unterschied naturgemäß nicht so stark herausgearbeitet, trotzdem steht selbst dort: „Die Methode getElementsByName() regelt lediglich den Zugriff auf HTML-Elemente.“

Jaja, wer lesen kann ... :-)
War auch ein gewisser Automatismus von mir, wenn getELementById() nicht richtig funktioniert getElementsByName() zu nehmen (und dann kraeftig zu fluchen, weil ich beim erstem Mal immer das Plural-s vergesse). Ja, der Automatismus ist schon recht alt ;-)

Ja, das könnte klarer formuliert sein, allerdings geschieht das eher in der Form einer für SELFHTML 9 geplanten Umstrukturierung des JS/DOM-Kapitels.

Moechtest Du mich versuchen? Sehe ich doch hinter der naechsten Ecke den Schatten schon, den da bildet das <I>. _So_ bloed bin ich dann auch wieder nicht :-)

so short

Christoph Zurnieden

PS:
Einen Fehler habe ich bei mir noch gefunden:[...]Id("r001").firstChild ist (beim Mozilla) ein Textknoten und nicht das gesuchte "cell".
CZ

[Christian Kruse]

你好 Christoph,

Ich muesste es zwar noch sorgfaeltig testen um es hieb- und stichfest zu
machen, aber das erlaubte getElementById() (bei mir zum Testen beliebt,
da es nur ein Element zuruekgibt, das spart den Aerger mit dem
Schleifchenbinden) funktioniert wohl nicht.

getElementById() kann nur funktionieren, wenn du

a) eine DTD benutzt, die die ID auch als soche definiert also, das
ID-Attribut als ID ausgezeichnet ist und
b) du einen validierenden XML-Parser benutzt (damit die DTD auch
ausgewertet wird).

a) kann ich bei dir nicht verifizieren, aber Opera hat keinen validierenden
XML-Parser ;) Von daher kann getElementById() bei reinen XML-Daten im
Opera nicht funktionieren.

再见,
 克里斯蒂安

[Tim Tepaße]

Hallo,

getElementById() kann nur funktionieren, wenn du
a) eine DTD benutzt, die die ID auch als soche definiert also, das
ID-Attribut als ID ausgezeichnet ist

oder

b) das Attribut xml:id benutzt, das laut Spezifikation automatisch den Typ ID hat und
b) einen nichtvalidierenden XML-Prozessor benutzt, der schon xml:id kennt, schließlich existiert dieses Attribut genau für diesen Fall. Ich bezweifele aber, dass es schon mehr als die zwei Implementationen existieren, die dafür verantwortlich waren, dass die xml:id Spezifikation den Status REC erreicht hat.

Tim

[molily]

Hallo,

b) das Attribut xml:id benutzt, das laut Spezifikation automatisch den Typ ID hat und
b) einen nichtvalidierenden XML-Prozessor benutzt, der schon xml:id kennt

Man kann auch einfach das id-Attribut aus dem Opera bekannten XHTML-Namespace verwenden, damit funktioniert getElementById in jedem XML-Dokument.

Mathias

[Christoph Zurnieden]

Hi,

Ich muesste es zwar noch sorgfaeltig testen um es hieb- und stichfest zu
machen, aber das erlaubte getElementById() (bei mir zum Testen beliebt,
da es nur ein Element zuruekgibt, das spart den Aerger mit dem
Schleifchenbinden) funktioniert wohl nicht.

getElementById() kann nur funktionieren, wenn du

a) eine DTD benutzt, die die ID auch als soche definiert also, das
ID-Attribut als ID ausgezeichnet ist und

Mein Versuch war also von Vornherein zum scheitern veurteilt, da das Einfuegen einer DTD wohl an ...

b) du einen validierenden XML-Parser benutzt (damit die DTD auch
ausgewertet wird).

... scheiterte.

a) kann ich bei dir nicht verifizieren,

Auch nicht, wenn Du in mein Posting schaust, in dem ich die Listings auffuehrte? ;-)

aber Opera hat keinen validierenden
XML-Parser ;) Von daher kann getElementById() bei reinen XML-Daten im
Opera nicht funktionieren.

Eine Gelegenheit mal wieder ein wenig OT zu gehen:
Ich verstehe so langsam nicht mehr, warum die Leute von Opera so begeistert sind. Selbst, wenn ich alles, was mir im Weg steht sorgfaeltig daraufhin pruefe, ob ich es nicht selber bin, der mir im Weg steht -- sprich: ich alter Sack mich einfach nicht mehr eingewoehnen kann -- und Dinge, die zumindest diskutabel waeren, bleibt noch allerhand das schlicht und ergreifend nicht bzw falsch funktioniert. Das groeste Manko dabei ist die voellig unzureichende Dokumentation. Bei einem kommerziellem Produkt ist das einfach nicht akzeptabel; ich kann Opera so bestimmt nicht meinen Kunden empfehlen, die einen speichersparenden aber trotzdem standardkonformen Browser benoetigen. Da bleibt nur die Fummelei mit einem KHTML-basiertem Browser. Dillo kann man ja leider schon alleine wegen der fehlenden UTF-Unterstuetzung nicht anbieten.

BTW: mit dem Dillo 6.5 aus Woody konnte ich hier posten, mit der aktuellen Version 8.5 kann ich es nicht mehr. Fehlermeldung war irgendetwas mit "falsche Zeichen" und eine Manipulationsvermutung. Muss ich mich durch Deinen Code wuehlen, oder koenntest Du mal schauen woran es genau lag, damit ich Dillo evt reparieren kann?

so short

Christoph Zurnieden

[Christian Kruse]

你好 Christoph,

BTW: mit dem Dillo 6.5 aus Woody konnte ich hier posten, mit der aktuellen
Version 8.5 kann ich es nicht mehr. Fehlermeldung war irgendetwas mit
"falsche Zeichen" und eine Manipulationsvermutung.

Das kann dann passieren, wenn du Zeichen eingibst, die in SGML bzw. HTML
nicht erlaubt sind oder von denen abgeraten wird. Oder meintest du die andere
Meldung? Du musst sie mir schon genau geben ;))

再见,
 克里斯蒂安

[Christoph Zurnieden]

Hi,

BTW: mit dem Dillo 6.5 aus Woody konnte ich hier posten, mit der aktuellen
Version 8.5 kann ich es nicht mehr. Fehlermeldung war irgendetwas mit
"falsche Zeichen" und eine Manipulationsvermutung.

Das kann dann passieren, wenn du Zeichen eingibst, die in SGML bzw. HTML
nicht erlaubt sind oder von denen abgeraten wird

Ach! ;-)

Oder meintest du die andere Meldung? Du musst sie mir schon genau geben ;))

Gut, ueberredet, ich probiere nochmal:
"Falsche oder fehlende Daten. Die Daten scheinen in irgendeiner Weise manipuliert worden zu sein."
Also doch nichts mit "falsche Zeichen" bitte um Entschuldigung.

Ah, das "Thema" ging irgendwo auf dem Wege verschuett. Na, mal schauen, aber wahrscheinlich wird mir eh die Zeit fehlen.

so short

Christoph Zurnieden

[Christian Kruse]

你好 Christoph,

"Falsche oder fehlende Daten. Die Daten scheinen in irgendeiner Weise
manipuliert worden zu sein."

Das kann unter diesen Umständen passieren:

• Das qchar-Feld wurde nicht übermittelt
• Der Input war _kein_ UTF-8 (&#255; ist nicht zu 0xC3 0xBF expandiert) und
  die Konvertierung nach UTF-8 ist fehlgeschlagen (kann eigentlich nur
  passieren, wenn ein iconv-Interner Fehler auftritt, sehr unwahrscheinlich)
• Input schien UTF-8 zu sein (&#255; ist zu 0xC3 0xBF expandiert) aber einer
  der Strings war doch kein richtiges[tm] UTF-8

Alle anderen Fehlerfälle geben andere Meldungen.

Ah, das "Thema" ging irgendwo auf dem Wege verschuett.

Nein, das wird generell nicht übermittelt in diesem Formular.

再见,
 克里斯蒂安

[Christian Kruse]

你好 Christoph,

a) kann ich bei dir nicht verifizieren,

Auch nicht, wenn Du in mein Posting schaust, in dem ich die Listings
auffuehrte? ;-)

Hey, ich sass, als ich die Antwort schrieb, im ASM-Tutorium, da kannst du
nicht erwarten, dass ich mir alles nochmal durchlese bevor ich etwas
schreibe! ;)

aber Opera hat keinen validierenden XML-Parser ;) Von daher kann
getElementById() bei reinen XML-Daten im Opera nicht funktionieren.

Eine Gelegenheit mal wieder ein wenig OT zu gehen:
Ich verstehe so langsam nicht mehr, warum die Leute von Opera so
begeistert sind.

Das ist im Gecko nicht anders, dito KHTML soweit ich mich erinnere. Die
einzigen, die einen validierenden Parser im Browser haben, sind Microsoft.

Selbst, wenn ich alles, was mir im Weg steht sorgfaeltig daraufhin
pruefe, ob ich es nicht selber bin, der mir im Weg steht -- sprich: ich
alter Sack mich einfach nicht mehr eingewoehnen kann -- und Dinge, die
zumindest diskutabel waeren, bleibt noch allerhand das schlicht und
ergreifend nicht bzw falsch funktioniert.

Kann ich nicht so recht nachvollziehen, aber ejal, ich will dir das mal
glauben ;))

Das groeste Manko dabei ist die voellig unzureichende Dokumentation.

Ja, die Dokumentation von Opera finde ich auch ziemlich übel. Die vom
Firefox finde ich aber nicht unbedingt besser. Nein, view the source ist
keine Alternative! ;)

再见,
 克里斯蒂安

[Christoph Zurnieden]

Hi,

Hey, ich sass, als ich die Antwort schrieb, im ASM-Tutorium, da kannst du
nicht erwarten, dass ich mir alles nochmal durchlese bevor ich etwas
schreibe! ;)

Seid ihr noch nicht beim Multithreading? >;->

Eine Gelegenheit mal wieder ein wenig OT zu gehen:
Ich verstehe so langsam nicht mehr, warum die Leute von Opera so
begeistert sind.

Das ist im Gecko nicht anders, dito KHTML soweit ich mich erinnere. Die
einzigen, die einen validierenden Parser im Browser haben, sind Microsoft.

Dafuer validiert der Parser nicht.
*luengelueng* 2 EUR in die Wortwitzkasse.

Wenn KHTML mit der LibXML gebaut wurde duerfte es zwar kein grosses Problem sein auch die Validierungsfaehigkeiten von LibXML zu nutzen, aber ich war auf die Kommerzialitaet des Browers aus und unter _der_ Voraussetzung fehlt der validierende XML-Parser, der in den freien Browsern einfach nicht drin ist. Noch dazu: die einzige kommerzielle Konkurenz hat ja einen drin!

bleibt noch allerhand das schlicht und
ergreifend nicht bzw falsch funktioniert.

Kann ich nicht so recht nachvollziehen, aber ejal, ich will dir das mal
glauben ;))

Alles unter dem Gesichtspunkt zu sehen, das es sich um ein kommerzielles Produkt handelt; die wollen damit schliesslich Geld verdienen!
Da sollte schon alles tadellos funktionieren, meinst Du nicht auch?

Das groeste Manko dabei ist die voellig unzureichende Dokumentation.

Ja, die Dokumentation von Opera finde ich auch ziemlich übel. Die vom
Firefox finde ich aber nicht unbedingt besser.

Die von Firefox kenne ich nicht sehr gut, aber die vom Mozilla kann man durchaus als ausreichend betrachten.

Nein, view the source ist keine Alternative! ;)

Das ist natuerlich keine Alternative zu einer guten Dokumentation, aber auf jeden Fall eine akzeptable gegenueber "gar nichts". Und immer ein guter Schiedsmann bei Streitigkeiten zwischen Dokumentation und Verhalten ;-)

Ich weiss ja nicht, was genau Nokia dazu bewogensem Formular.

hat auf KHTML zu setzen -- jeder hatte sich schliesslich gefragt: warum denn nicht Opera? -- aber einige der Gruende koennte ich mittlerweile aufzaehlen.

Ich ziehe mal die Postings zusammen, wenn's erlaubt:

• Das qchar-Feld wurde nicht übermittelt
• Der Input war _kein_ UTF-8 (&#255; ist nicht zu 0xC3 0xBF expandiert) und
  die Konvertierung nach UTF-8 ist fehlgeschlagen (kann eigentlich nur
  passieren, wenn ein iconv-Interner Fehler auftritt, sehr unwahrscheinlich)
• Input schien UTF-8 zu sein (&#255; ist zu 0xC3 0xBF expandiert) aber einer
  der Strings war doch kein richtiges[tm] UTF-8

Ah, danke, dann habe ich schonmal einen Ansatz.

Ah, das "Thema" ging irgendwo auf dem Wege verschuett.

Nein, das wird generell nicht übermittelt in diesem Formular.

Einen hier auf die falsche Faehrte locken, datt hamm wa gerne!
*grummel*
;-)

so short

Christoph Zurniede

[Christian Kruse]

你好 Christoph,

Hey, ich sass, als ich die Antwort schrieb, im ASM-Tutorium, da kannst
du nicht erwarten, dass ich mir alles nochmal durchlese bevor ich etwas
schreibe! ;)

Seid ihr noch nicht beim Multithreading? >;->

Glücklicherweise nicht ;)

[...] aber ich war auf die Kommerzialitaet des Browers aus und unter
_der_ Voraussetzung fehlt der validierende XML-Parser, der in den freien
Browsern einfach nicht drin ist. Noch dazu: die einzige kommerzielle
Konkurenz hat ja einen drin!

Naja, das sehe ich anders. Opera kost ja nix. Is ja umsonst, hat ja
nichtmal Werbung. Und dass die sowas in die Embedded-Version nicht
einbauen, das versteh ich gut, würd ich auch nicht ;)

Das groeste Manko dabei ist die voellig unzureichende Dokumentation.

Ja, die Dokumentation von Opera finde ich auch ziemlich übel. Die vom
Firefox finde ich aber nicht unbedingt besser.

Die von Firefox kenne ich nicht sehr gut, aber die vom Mozilla kann man
durchaus als ausreichend betrachten.

Das ist Ansichtssache, ich finde sie mieserabel.

Nein, view the source ist keine Alternative! ;)

Das ist natuerlich keine Alternative zu einer guten Dokumentation, aber
auf jeden Fall eine akzeptable gegenueber "gar nichts".

Für dich. Für mich vielleicht auch nicht. Aber für $WEBDESIGNER nicht, für
den ist das genau so als wenn es closed source und undokumentiert wäre.

Ich ziehe mal die Postings zusammen, wenn's erlaubt:

Naja. Ausnahmsweise. ;))

再见,
 克里斯蒂安

[Christoph Zurnieden]

Hi,

[...] aber ich war auf die Kommerzialitaet des Browers aus und unter
_der_ Voraussetzung fehlt der validierende XML-Parser, der in den freien
Browsern einfach nicht drin ist. Noch dazu: die einzige kommerzielle
Konkurenz hat ja einen drin!

Naja, das sehe ich anders. Opera kost ja nix. Is ja umsonst, hat ja
nichtmal Werbung.

Wenn die ein derartiges Geschaeftsmodel waehlen ist das nicht mein Problem, es tut der Kommerzialitaet von Opera keinen Abbruch. Hier geht es um die Lizenz nicht um den Preis. Richtig umsonst ist er auch nicht, er hat mich schon einige Stunden gekostet und ich bin nicht gerade billig.
Wo wir gerade beim Preis sind: findest Du irgendwo auf der Opera-Seite Preise?

Und dass die sowas in die Embedded-Version nicht
einbauen, das versteh ich gut, würd ich auch nicht ;)

Nein, ich muss hier die normale x386er Version nutzen, die gibt es nicht in "abgespeckt".

Die von Firefox kenne ich nicht sehr gut, aber die vom Mozilla kann man
durchaus als ausreichend betrachten.

Das ist Ansichtssache, ich finde sie mieserabel.

Die aus dem Quellcode gezogene API-Dokumentation ist nicht schlecht.
Aber gut, wenn man hauptsaechlich mit Openource-Software zu tun hat sind die Ansprueche an Dokumentation nicht mehr gar so hoch, das mag wohl sein ;-)

Nein, view the source ist keine Alternative! ;)

Das ist natuerlich keine Alternative zu einer guten Dokumentation, aber
auf jeden Fall eine akzeptable gegenueber "gar nichts".

Für dich. Für mich vielleicht auch nicht. Aber für $WEBDESIGNER nicht, für
den ist das genau so als wenn es closed source und undokumentiert wäre.

Mmh...dann waeren wir ja mal wieder erfolgreich bei der grundsaetzlichen Frage angekommen: nach Standard oder fuer die Browser schreiben?
Heisst die Antwort: nach Standard! gelten die Seiten des W3C und sonst gar nichts. Haelt sich ein Browser nicht daran ist es die eindeutige Schuld des Browsers.
Heisst die Antwort: fuer die Browser! muss man die Browser genau kennen. Gibt es keine Dokumentation und nur den Quellcode muss $WEBDESIGNER den eben lesen koennen. Oder es gibt eine Dokumentation vom Drittanbieter z.B. SELFHTML. Bei Browsern ohne Dokumentation und ohne Quellcode muss ja das Verhalten ausgetestet werden bzw decompiliert. Das Verhalten eines Browsers vollstaendig
auszutesten ist schon theoretisch nicht moeglich und eine Decompilierung ist es bei so komplexen Gebilden in praxi nicht.
Die einzige Moeglichkeit waere nun nach Standard zu schreiben oder -- die urspruengliche Frage umzuformulieren.

so short

Christoph Zurnieden

[Christian Kruse]

你好 Christoph,

Wo wir gerade beim Preis sind: findest Du irgendwo auf der Opera-Seite
Preise?

Sicher, auf einen Klick: http://opera.com/buy/ ;)

Nein, view the source ist keine Alternative! ;)

Das ist natuerlich keine Alternative zu einer guten Dokumentation,
aber auf jeden Fall eine akzeptable gegenueber "gar nichts".

Für dich. Für mich vielleicht auch nicht. Aber für $WEBDESIGNER nicht,
für den ist das genau so als wenn es closed source und undokumentiert
wäre.

Mmh...dann waeren wir ja mal wieder erfolgreich bei der grundsaetzlichen
Frage angekommen: nach Standard oder fuer die Browser schreiben?
Heisst die Antwort: nach Standard! gelten die Seiten des W3C und sonst
gar nichts. Haelt sich ein Browser nicht daran ist es die eindeutige
Schuld des Browsers.

Eine derartige Einstellung wäre als weltfremd zu bezeichnen. Browser haben
Fehler und/oder Eigenheiten (neutral formuliert), und das wird sich nie
ändern. Und die gehören ordentlich und sauber dokumentiert!

再见,
 克里斯蒂安

[Christoph Zurnieden]

Hi,

Wo wir gerade beim Preis sind: findest Du irgendwo auf der Opera-Seite
Preise?

Sicher, auf einen Klick: http://opera.com/buy/ ;)

Dann weisst Du ja jetzt warum es rein gar keine Dokumentation gibt ;-)

Aber Scherz beiseite: Wirklich Geld verdienen die nur mit handangepassten Produkten und grossen Stueckzahlen (auch wenn mir das Wort "Stueckzahl" bei Software fast schon koerperliche Schmerzen bereitet). Die Preise dafuer findest Du nicht auf der Seite. Noch nicht einmal das beruehmte  "a. A.".
Die potentiellen Kunden ihrer Kunden mit mangelhafter Ware "anzufixen" sollte also eigentlich nicht in ihrem Interesse liegen.
Wo sich jetzt auch noch Nokia fuer ein Opensource-Produkt entschieden hat. (Oder die wollen einfach nur den Preis druecken, ist natuerlich auch moeglich)

Mmh...dann waeren wir ja mal wieder erfolgreich bei der grundsaetzlichen
Frage angekommen: nach Standard oder fuer die Browser schreiben?
Heisst die Antwort: nach Standard! gelten die Seiten des W3C und sonst
gar nichts. Haelt sich ein Browser nicht daran ist es die eindeutige
Schuld des Browsers.

Eine derartige Einstellung wäre als weltfremd zu bezeichnen.

Aber dsa tust Du nicht. Oder warum der Konjunktiv?
Ist es denn wirklich so abwegig fuer ein mangelhaftes Produkt Nachbesserung zu verlangen? Wenn zudem der Hersteller sogar noch im Standardkomitee mit drinsitzt ...
Fehlerfreiheit ist bei Software natuerlich unbezahlbar fuer alles, was eine gewisse Komplexitaetsgreze ueberschreitet. Allerdings: als gelegentlicher Nutzer der modernen Verkehrsfliegerei haette ich schon gerne, das zumindest in dem Bereich fehlerfreie Software eingesetzt wird ;-)

Browser haben
Fehler und/oder Eigenheiten (neutral formuliert), und das wird sich nie
ändern. Und die gehören ordentlich und sauber dokumentiert!

Alle Fehler aufschreiben?
Waere es denn dann nicht einfacher, wenn die Browserhersteller einfach den Standard abbarbeiten wuerden? Aber gut, dann muessten die natuerlich wirklich etwas bieten, damit die Leute sie auch benutzen >;->

so short

Christoph Zurnieden

[Christian Kruse]

你好 Christoph,

Die potentiellen Kunden ihrer Kunden mit mangelhafter Ware "anzufixen"
sollte also eigentlich nicht in ihrem Interesse liegen.

Ich sagte ja schon mehrfach, dass ich nicht finde, Opera ist mangelhafte
Ware :)

Wo sich jetzt auch noch Nokia fuer ein Opensource-Produkt entschieden
hat. (Oder die wollen einfach nur den Preis druecken, ist natuerlich
auch moeglich)

Das werden wir sehen, wenn sie fertig sind ;)

Mmh...dann waeren wir ja mal wieder erfolgreich bei der
grundsaetzlichen Frage angekommen: nach Standard oder fuer die
Browser schreiben? Heisst die Antwort: nach Standard! gelten die
Seiten des W3C und sonst gar nichts. Haelt sich ein Browser nicht
daran ist es die eindeutige Schuld des Browsers.

Eine derartige Einstellung wäre als weltfremd zu bezeichnen.

Aber dsa tust Du nicht. Oder warum der Konjunktiv?

Doch, das tue ich. Der Konjunktiv, weil ich dir unterstelle, dass du eine
solche Einstellung _nicht_ an den Tag legst ;)

Ist es denn wirklich so abwegig fuer ein mangelhaftes Produkt
Nachbesserung zu verlangen?

Nein. Aber abwegig ist es zu glauben, dass jeder Benutzer das Update für
die Behebung der Mängel fährt.

Allerdings: als gelegentlicher Nutzer der modernen Verkehrsfliegerei
haette ich schon gerne, das zumindest in dem Bereich fehlerfreie
Software eingesetzt wird ;-)

Hehe, ja, das sehe ich ähnlich ;)

Browser haben Fehler und/oder Eigenheiten (neutral formuliert), und das
wird sich nie ändern. Und die gehören ordentlich und sauber
dokumentiert!

Alle Fehler aufschreiben?

Selbstverständlich! Inkl. Versions-Historie (wann wurde er gefixt, wann trat
er zum ersten mal auf, etc). Ich verstehe ja, wenn das ein Kleinst-Projekt
nicht tut. Aber so grosse Projekte wie Mozilla?

再见,
 克里斯蒂安

[Christoph Zurnieden]

Hi,

Die potentiellen Kunden ihrer Kunden mit mangelhafter Ware "anzufixen"
sollte also eigentlich nicht in ihrem Interesse liegen.

Ich sagte ja schon mehrfach, dass ich nicht finde, Opera ist mangelhafte
Ware :)

Mangelhaft im Sinne von z.B. Stiftung Warentest ist er nicht. da er im Grunde natuerlich ganz gut funktioniert. Er haelt jedoch die aktuellen Webstandards nicht ein, deshalb ist er mit Maengeln behaftet. Da stoert es auch nicht, das es sonst auch keiner tut und er zusammen mit den auf Gecko bzw KHTML basierenden Browsern eine gute Position auf den Spitzenplaetzen haelt. Es ist ein kommerzielles Produkt mit harter Konkurenz und muss es sich also gefallen lassen auch den kleinsten Fehler vorgehalten zu bekommen. Opera ist aber natuerlich zu Gute zu halten, das sie die Beschwerden ernstnehmen und sich um Besserung bemuehen. Wie man so hoert sogar teilweise besser, als die direkte Konkurenz.
Ich kann also die Begeisterungsstuerme der Nutzer nicht verstehen, weil es nicht mehr als ein ganz guter Browser ist -- aber auch nicht weniger, klar.

Wo sich jetzt auch noch Nokia fuer ein Opensource-Produkt entschieden
hat. (Oder die wollen einfach nur den Preis druecken, ist natuerlich
auch moeglich)

Das werden wir sehen, wenn sie fertig sind ;)

Ja, dieses Jahr wird's wohl nichts mehr, nehme ich an.
Aber interessant ist es schon, das sie KHTML gewaehlt haben. Im Embeddedbereich gibt es schon noch einiges mehr an Auswahl als fuer den PC. Aber so richtig "embeded" ist ein modernes Telephon auch nicht mehr, das sind schon richtige Rechner mit ordentlich Speicher :-)

Eine derartige Einstellung wäre als weltfremd zu bezeichnen.

Aber dsa tust Du nicht. Oder warum der Konjunktiv?

Doch, das tue ich. Der Konjunktiv, weil ich dir unterstelle, dass du eine
solche Einstellung _nicht_ an den Tag legst ;)

Unterstellungen sind mir gegenueber immer gefaehrlich. Hinter Dir koennte durchaus jemand stehen und mir mit Bargeld winken ;-)

Ist es denn wirklich so abwegig fuer ein mangelhaftes Produkt
Nachbesserung zu verlangen?

Nein. Aber abwegig ist es zu glauben, dass jeder Benutzer das Update für
die Behebung der Mängel fährt.

Einerseits kann man natuerlich sagen, das der, der Nachbesserungen verlangt auch seine Teil dazu tun muss. Wer das Klappern an seinem Neuwagen abgestellt haben will, muss dem Verkaeufer auch die Gelegenheit dazu geben und den Wagen zwecks Reparatur ueberlassen. Simile claudicant, so natuerlich auch hier: es ist ein Unterschied ob ich Software (automatisch) patchen lassen oder einer einer KFZ-Vertragswerkstatt mit Angst im Nacken in den Hintern trete das Klappern abzustellen. Einer Werkstatt vetraue ich im Prinzip obwohl es recht viele schwarze Schafe gibt, die nicht sofort erkennbar sind aber einem Softwarehersteller vertraue ich aus Prinzip erstmal nicht, obwohle es nur wenige schwarze Schafe gibt, die zudem gut zu erkennen sind.
Die wenigen haben aber leider einen sehr grossen Verbreitungsgrad mit ihren Produkten. Ich kann es verstehen, das die Leute stinkig werden, wenn nach einer Bremsenreparatur der Motor nicht mehr laeuft. Die werden es sich beim naechstem Mal dreimal ueberlegen und evt zu dem Schluss kommen, das die besten Bremsen nichts nutzen, wenn es nichts zum abbremsen gibt und sich die Reparatur schenken. Irgendwie werden ich das dumme Gefuehl nicht los, das der Vergleich nicht ganz so hinkt, wie sich das Sprichwort es vorstellt ;-)
Na, kurz und gut: es ist dafuer zu sorgen, das Sicherheitspatches nicht die Funktion behindern. Kleinigkeiten duerfen sein: "Die Bremsen sind in Ordnung, nur das Radio ist augenblicklich nur noch Mono, das passende Ersatzteil kommt leider erst in den naechsten Tagen rein, wir sagen Bescheid.". Dann noch ordentlich Werbung dafuer und Geduld gezeigt. Vielleicht funktioniert's ja irgendwann einmal.

Alle Fehler aufschreiben?

Selbstverständlich! Inkl. Versions-Historie (wann wurde er gefixt, wann trat
er zum ersten mal auf, etc). Ich verstehe ja, wenn das ein Kleinst-Projekt
nicht tut. Aber so grosse Projekte wie Mozilla?

Hau mich bloss mit denen ab, die habe ich schon lange gefressen! Keine Diffs, Fehler, vor allem unangenehme werden geheimgehalten und mit einem './configure && make && make install' kannst Du fast alles bauen, nur keinen Mozilla. Die Sache mit der Build-in SVG-Unterstuetzung natuerlich auch nicht zu vergessen! Es wundert einen schon sehr, wie die ueberhaupt so ein gutes Projekt auf die Beine gestellt haben.
Dieser Rant kommt allerdings von jemandem, der auf ordentliche Diffs und Fehlerbeschreibungen angewiesen ist, da ich eine aus Sicherheitsgruenden stark gerippte Mozillafassung an meine Kunden verteile, ich kann also keine Patches einspielen, sondern muss aus den Quellen neubauen. Das bedeutet: jedesmal ueber 50 MiBs uebers Modem zuzeln, Diff erstellen, lebenswichtige Aenderungen raussuchen und Rest wegschmeissen, Diff einspielen, Neubau versuchen (klappt selten gleich beim erstem Mal und dauert auch recht lange auf einem Duron 1200), testen und schlussendlich auch noch einen Binarypatch erstellen. Ab "Neubau" fuer alle unterstuetzten Architekturen und Betriebsysteme wiederholen.
Gottseidank ist ein Patch aber auch nur alle Jubeljahre faellig, da ich viel rausgeschmissen habe. Nichtsdestotrotz muss ich die Codebasis aber immer aktuell halten, da hat man stets gut zu tun.
Und am Ende beschweren sich die Kunden noch darueber, das man dafuer ein paar Euro auf die Rechnung setzt:"Aber der Mozilla ist doch gratis!" *sigh*
Aber jetzt genug gejammert und ein Tomatenbrot geschmiert ;-)

Mahlzeit

Christoph Zurnieden

[Christian Kruse]

你好 Christoph,

Wo sich jetzt auch noch Nokia fuer ein Opensource-Produkt entschieden
hat. (Oder die wollen einfach nur den Preis druecken, ist natuerlich
auch moeglich)

Das werden wir sehen, wenn sie fertig sind ;)

Ja, dieses Jahr wird's wohl nichts mehr, nehme ich an.
Aber interessant ist es schon, das sie KHTML gewaehlt haben.

Vermutlich alle, die für Nokia-Handies entwickeln ;)

Ist es denn wirklich so abwegig fuer ein mangelhaftes Produkt
Nachbesserung zu verlangen?

Nein. Aber abwegig ist es zu glauben, dass jeder Benutzer das Update für
die Behebung der Mängel fährt.

Einerseits kann man natuerlich sagen, das der, der Nachbesserungen
verlangt auch seine Teil dazu tun muss.

Wenn ich verlange, dass das Auto von XYZ repariert wird, interessiert XYZ
das noch lange nicht ;) Genausowenig wie es XYZ interessiert, dass ich gern
hätte, dass alle Leute einen aktuellen, gepatchten IE bzw. einen aktuellen
Firefox bzw. einen aktuellen … benutzen. Möchten kann ich viel ;)

Alle Fehler aufschreiben?

Selbstverständlich! Inkl. Versions-Historie (wann wurde er gefixt, wann
trat er zum ersten mal auf, etc). Ich verstehe ja, wenn das ein
Kleinst-Projekt nicht tut. Aber so grosse Projekte wie Mozilla?

Hau mich bloss mit denen ab, die habe ich schon lange gefressen!

*hrhrhr* ;)

再见,
 克里斯蒂安

[Christoph Zurnieden]

Hi,

Ja, dieses Jahr wird's wohl nichts mehr, nehme ich an.
Aber interessant ist es schon, das sie KHTML gewaehlt haben.

Vermutlich alle, die für Nokia-Handies entwickeln ;)

Da grinst er -- noch! >;->

Wenn ich verlange, dass das Auto von XYZ repariert wird, interessiert XYZ
das noch lange nicht ;)

Du bist aber heute mal wieder kleinlich!
Liegt das am Assemblerkurs? ;-)

Gut: es geht hier speziell um die kommerzielle Variante und um Vorfaelle innerhalb der Garantiezeit und auch speziell waehrend der Gewaehrleistungsfrist. Deshalb ist das evt von mittleren Summen Bargekd gestuetzte Verlangen nach einem namentlich genannten Mechaniker fuer die Reparatur ausnahmsweise einmal nicht relevant, es geht nur um die Beseitigung eines Mangels innerhalb der Gewaehrleistungsfrist.
Interessant dabei und ebenfalls nicht angeschnitten wurden die eklatanten Schwierigkeiten bei der Definition von "Mangel".

Genausowenig wie es XYZ interessiert, dass ich gern
hätte, dass alle Leute einen aktuellen, gepatchten IE bzw. einen aktuellen
Firefox bzw. einen aktuellen … benutzen. Möchten kann ich viel ;)

Das Gesetz wuerde Dich allerdings bei so einigem unterstuetzen. Jedoch ist das bis jetzt nur bei den Bremsen der Fall, nicht bei Sicherheitsloechern, die einem Angreifer erlauben z.B. die Adresse der Besitzerin des Sicherheitsloches herauszubekommen, dahin zu fahren und gewisse aeusserst unapetittliche Dinge mit ihr zu tun, die naeher zu beschreiben ich mir hier schenke.
Ausserdem hoere ich gerade BWV 249, da gehoert sich sowas nicht.

Aber so grosse Projekte wie Mozilla?

Hau mich bloss mit denen ab, die habe ich schon lange gefressen!

*hrhrhr* ;)

Du hast gut lachen; ich habe jedoch keine Alternative, den im Gegensatz zu Microsoft und anderen grossen Software-Firmen bin ich faellig, wenn etwas "fahrlaessig" (nein, nicht nur "grob fahrlaessig"!) schief geht.
Aber gut: bei _meinen_ Preisen koennen die Leute ja auch mit Fug und Recht reichlich verlangen ;-)

so short

Christoph Zurnieden

[Christian Kruse]

你好 Christoph,

Ja, dieses Jahr wird's wohl nichts mehr, nehme ich an.
Aber interessant ist es schon, das sie KHTML gewaehlt haben.

Vermutlich alle, die für Nokia-Handies entwickeln ;)

Da grinst er -- noch! >;->

Hehe – solange ich grinsen kann tue ich das auch ;)

Wenn ich verlange, dass das Auto von XYZ repariert wird, interessiert
XYZ das noch lange nicht ;)

Du bist aber heute mal wieder kleinlich!
Liegt das am Assemblerkurs? ;-)

Kleinlich? Ich habe doch nur eine Seite deiner Argumentation aufgedeckt,
die du IMHO völlig ausser acht gelassen hast ;)

Gut: es geht hier speziell um die kommerzielle Variante und um Vorfaelle
innerhalb der Garantiezeit und auch speziell waehrend der
Gewaehrleistungsfrist. Deshalb ist das evt von mittleren Summen Bargekd
gestuetzte Verlangen nach einem namentlich genannten Mechaniker fuer die
Reparatur ausnahmsweise einmal nicht relevant, es geht nur um die
Beseitigung eines Mangels innerhalb der Gewaehrleistungsfrist.

Mag ja alles sein, aber auch ein Kunde, der nicht zahlen muss, geht nicht
unbedingt zur Ausbesserung mit seinem Wagen. Dafür müsste er ja etwa zwei
Tage auf ihn verzichten.

Ausserdem hoere ich gerade BWV 249, da gehoert sich sowas nicht.

*rotfl*

Du hast gut lachen; ich habe jedoch keine Alternative, den im Gegensatz
zu Microsoft und anderen grossen Software-Firmen bin ich faellig, wenn
etwas "fahrlaessig" (nein, nicht nur "grob fahrlaessig"!) schief geht.

Weisst du, da habe ich kein Mitleid ;) Du hast dir dein Los schliesslich
selber ausgesucht ;)

Aber gut: bei _meinen_ Preisen koennen die Leute ja auch mit Fug und
Recht reichlich verlangen ;-)

Einsicht ist der erste Schritt zur Besserung *g*

再见,
 克里斯蒂安

[Christoph Zurnieden]

Hi,

Wenn ich verlange, dass das Auto von XYZ repariert wird, interessiert
XYZ das noch lange nicht ;)

Du bist aber heute mal wieder kleinlich!
Liegt das am Assemblerkurs? ;-)

Kleinlich? Ich habe doch nur eine Seite deiner Argumentation aufgedeckt,
die du IMHO völlig ausser acht gelassen hast ;)

Ja, und mit Absicht. Es gibt auch noch einige andere Seiten, die ich nicht erwaehnte und nicht unbedingt aus dem Grund der Mengenbegrenzung hier. Damit das hier nicht zu einem privatem Streitgespraech in golemscher hoeherer Metasprache wird wollte ich die Beispiele moeglichst einfach halten.

Mag ja alles sein, aber auch ein Kunde, der nicht zahlen muss, geht nicht
unbedingt zur Ausbesserung mit seinem Wagen. Dafür müsste er ja etwa zwei
Tage auf ihn verzichten.

In Laufe der Gewaehrleistungsfrist gibt es fuer gewoehnlich einen Leihwagen meist sogar hoeherer Klasse. Schon lange keinen Neuwagen mehr gekauft, was? ;-)
Zudem: laesst er seine Bremsen nicht reparieren und ihm kann Kenntnis ueber den Zustand seiner Bremsen nachgewiesen werden (sehr einfach, wenn es z. B. eine Rueckrufaktion gegeben hat, das wird dann schwierig sich da rauszuwinden) ist er fuer Folgeschaeden haftbar. Auch wenn kein Schaden enstanden ist kann es teuer werden, wenn er sich erwischen laesst.

Ausserdem hoere ich gerade BWV 249, da gehoert sich sowas nicht.

*rotfl*

Sieh an, Du verstehst die Scherze auch, wenn sie um mehr als 3 Ecken gehen, Respekt!

Du hast gut lachen; ich habe jedoch keine Alternative, den im Gegensatz
zu Microsoft und anderen grossen Software-Firmen bin ich faellig, wenn
etwas "fahrlaessig" (nein, nicht nur "grob fahrlaessig"!) schief geht.

Weisst du, da habe ich kein Mitleid ;) Du hast dir dein Los schliesslich
selber ausgesucht ;)

Haette ich das nicht, haette ich vielleicht nix mehr zu meckern und waere dann auch wieder unzufrieden ;-)

Aber gut: bei _meinen_ Preisen koennen die Leute ja auch mit Fug und
Recht reichlich verlangen ;-)

Einsicht ist der erste Schritt zur Besserung *g*

Ja, wenn ich komme haben sogar Oracle-Mitarbeiter sofort alles fallen zu lassen.
Aber ich bin ja nicht so und habe sogar einmal den Tierschutz verstaendigt, weil selbst ich die Behandlung der MSCEs nicht mehr tolerieren konnte.

BTW: ich war letzthin bei einer meiner Kunden, die ambulante Altenpflege betreiben. Sollte man sich ja fruehzzeitig warmhalten, sowas. Da geht das, selbstverstaendlich voellig unbestaetigte Geruecht, das sie im Zuge der Arbeitsmarktreform und Regierungsumbildung demnaechst alles Faelle von de Cubitus als offene Stellen dem Arbeitsamt zu melden haetten. Aber das ist natuerlich noch nicht in trockenen Tuechern.

so short

Christoph Zurnieden

[Orlando]

Hallo Christoph,

Da wollte ich es aber nun ein wenig ordentlich machen und musste feststellen, das ich auf eine XML-Anfrage einen 304 zurueckbekomme, da der Opera (8.5) eine entsprechende Anfrage stellt (aber noch nicht geprueft, nur eine Vermutung).

Für Opera 9 Technical Preview 1 sagt das Changelog:

| XMLHttpRequest returns the status code for the cached page
| if the request returns the cached page.

Downloads für Windows / Mac / Unix: http://my.opera.com/community/forums/topic.dml?id=108345

Grüße
 Roland

[Christian Kruse]

你好 Orlando,

Für Opera 9 Technical Preview 1 sagt das Changelog:

| XMLHttpRequest returns the status code for the cached page
| if the request returns the cached page.

Downloads für Windows / Mac / Unix: http://my.opera.com/community/forums/topic.dml?id=108345

Hehe ;) Ich surfe jetzt seit etwa 20 Minuten mit dem Ding. Scheint nett zu
sein ;)

再见,
 克里斯蒂安

[Christoph Zurnieden]

Hi,

Für Opera 9 Technical Preview 1 sagt das Changelog:

nichts, was mich ueberzeugen koennte den Aerger mit Mozilla in die sprichwoertliche Tonne zu hauen und zu Opera zu wechseln.
BTW: gibt es eigentlich fuer den 8.5 das noetige Sicherheitsupdate und wenn ja: seit wann?

| XMLHttpRequest returns the status code for the cached page
| if the request returns the cached page.

Entweder gehorcht mir der Opera auf's Wort oder dokumentiert davon abweichendes Verhalten sorgfaeltig, aber sowas? Was wird damit repariert?
Ich habe mich darueber echauffiert, das der Opera mir nicht auf's Wort gehorcht und, nunja, bescheiden dokumentiert ist, nicht ueber den 304 an sich. Der ist zwar bei diesem -- hier allerdings unverlangtem! -- bedingtem GET nicht direkt vorgeschrieben, aber zumindest korrekt behandelt worden; der bloede Hund war ich, der ich nicht in's RFC geschaut hatte, bevor ich meine Stimme erhob.

Aber was soll das da oben eigentlich genau bedeuten?
Wenn die erhaltene Seite gleich der Seite ist, die im Cache liegt, wird der Statuscode erklaert, der beim erstmaligem Erhalt der Seite vom Server zurueckgegeben wurde. Nicht der, den der Server bei der aktuellen Anfrage zurueckgegeben hat und durchaus unterschiedlich zum erstem Mal sein kann? Das kann ja bei autogenerierten Seiten durchaus vorkommen, das der Inhalt gleich, doch der Statuscode ein anderer ist. Was wird ueberhaupt verglichen? Die Daten oder die Angaben im Header (E-Tag)? Koennte es jetzt vorkommen, das ich auf einen 304 "nix passiert!" vergeblich warte? Fragen ueber Fragen.

Eine einzige ver!#@*&te Zeile in der Dokumentation haette doch gereicht, warum etwas aendern? Weil ueberhaupt keine Dokumentation vorhanden ist, in die man diese Zeile haette einschieben koennen?

So ein schoener Browser -- so ein Murks.
Kann ich ja gleich beim IE bleiben.

BTW: warum kann ich eigentlich keine eigenen Ordner im Mailapp vom Opera erstellen und meine Post dort einsortieren? Bin ich da nur zu bloed zu (sehr wahrscheinlich) oder geht das wirklich nicht (wuerde mich doch sehr wundern)?

Aber mal meine schlechten Scherze beiseite: hat eigentlich irgendjemand mit denen geschaeftliche Erfahrung? Was kostet das Dingen? Die oeffentliche Preisliste kenne ich, die interessiert mich nicht die Bohne. Nein: was kostet mich die Quelleneinsicht, was kosten mich Aenderungswuensche, was kostet mich die Lizenz, wenn ich diese Aenderungen selber durchfuehren will und das Ergebniss verbreiten usw. Gut, das kann ich auch schlicht anfragen, aber nur die Erfahrung anderer kann mir sagen, was es mich an _Nerven_ kosten wuerde.

so short

Christoph Zurnieden

[Ashura]

Hallo Christoph.

BTW: warum kann ich eigentlich keine eigenen Ordner im Mailapp vom Opera erstellen und meine Post dort einsortieren? Bin ich da nur zu bloed zu (sehr wahrscheinlich) oder geht das wirklich nicht (wuerde mich doch sehr wundern)?

M2 ist nicht mit anderen Mailclients vergleichbar.
Es gibt keine Ordner, du kannst „lediglich“ Filter anlegen, welche dir dann nur die von dir gewünschten Mails anzeigen.

Siehe hierzu auch http://opera.com/support/tutorials/mail/.

Einen schönen Donnerstag noch.

Gruß, Ashura

[molily]

Hallo,

| XMLHttpRequest returns the status code for the cached page
| if the request returns the cached page.

Wenn die erhaltene Seite gleich der Seite ist, die im Cache liegt, wird der Statuscode erklaert, der beim erstmaligem Erhalt der Seite vom Server zurueckgegeben wurde. Nicht der, den der Server bei der aktuellen Anfrage zurueckgegeben hat und durchaus unterschiedlich zum erstem Mal sein kann? Das kann ja bei autogenerierten Seiten durchaus vorkommen, das der Inhalt gleich, doch der Statuscode ein anderer ist.

Ich nehme an, es handelt sich nur um die Geschichte mit 200 und 304.
»If the request returns the cached page« - damit kann nur 304 gemeint sein. Ansonsten wäre die Neuerung widersinnig. Wenn der Server mit 200 und einem Response Body antwortet, wäre es unsinnig, den Statuscode der zwischengespeicherten Ressource zu verwenden (der aber dann sinnigerweise auch nur 200 sein kann).

Was wird ueberhaupt verglichen? Die Daten oder die Angaben im Header (E-Tag)? Koennte es jetzt vorkommen, das ich auf einen 304 "nix passiert!" vergeblich warte? Fragen ueber Fragen.

Wie, verglichen? Opera vergleicht mit Sicherheit keine Ressourcen selbst, sondern sendet schlichtweg beim zweiten (konditionalen) Request auf dieselbe Ressource den Entity-Tag zurück, den der Server beim ersten gesendet hat.
Was meinst du mit vergeblich warten auf 304?

Eine einzige ver!#@*&te Zeile in der Dokumentation haette doch gereicht, warum etwas aendern?

Weil viele Scripte einfach XMLHttpRequest.status == 200 prüfen, weil sie dieses Verhalten vom Browser erwarten.

BTW: warum kann ich eigentlich keine eigenen Ordner im Mailapp vom Opera erstellen und meine Post dort einsortieren?

Weil Opera Mail-Client nicht ordnerbasiert arbeitet. *Das* steht aber groß und breit in der Dokumentation.

Mathias

[Christoph Zurnieden]

Hi,

»» »» »» | XMLHttpRequest returns the status code for the cached page
»» »» »» | if the request returns the cached page.

»» Ich nehme an, es handelt sich nur um die Geschichte mit 200 und 304.

Nein, um den Satz da oben.

»» »If the request returns the cached page« - damit kann nur 304 gemeint sein.

Ein 304 hat keinen Messagebody ("MUST NOT" steht in der RFC), der gibt also keine Seite zurueck.

»» Ansonsten wäre die Neuerung widersinnig.

Eben, deshalb meine Fragen.

»» »» Was wird ueberhaupt verglichen? Die Daten oder die Angaben im Header (E-Tag)? Koennte es jetzt vorkommen, das ich auf einen 304 "nix passiert!" vergeblich warte? Fragen ueber Fragen.
»»
»» Wie, verglichen? Opera vergleicht mit Sicherheit keine Ressourcen selbst,

Das steht da aber: "if the request returns the cached page"

»» Was meinst du mit vergeblich warten auf 304?

Es ist eine Art Watchdog-Funktion moeglich, die auf ein Ereignis wartet und dies durch regelmaessige Abfragen prueft, bei einem 304 ist eben "nix passiert". Meist waere dabei allerdings ein 202er passender, da da evt noch ein Status mitgeschickt wird, da hast Du natuerlich Recht. Jedoch setzt ein 202er stillschweigend voraus, das ein Ereignis bereits eingetreten und nur noch nicht fertig ist.

»» »» Eine einzige ver!#@*&te Zeile in der Dokumentation haette doch gereicht, warum etwas aendern?
»»
»» Weil viele Scripte einfach XMLHttpRequest.status == 200 prüfen, weil sie dieses Verhalten vom Browser erwarten.

Was hat denn der Browser, also der Client mit den Statuscodes am Hut, die der Server auswirft?
Das ist aber auch recht typisch fuer kommerzielle Software. Die muessen verkaufen und richten sich daher streng nach dem Kunden, nicht unbedingt streng nach den Standards, wenn dies die Kunden nicht tun/verlangen.
Ist aber durchaus in Ordnung, wenn dieses Verhalten auch ordentlich dokumentiert wird. Wenn die ihren Satz aus dem ChangeLog so formulieren, das er auch verstaendlich wird, waere diese Bedingung ja schon erfuellt.

»» »» BTW: warum kann ich eigentlich keine eigenen Ordner im Mailapp vom Opera erstellen und meine Post dort einsortieren?
»»
»» Weil Opera Mail-Client nicht ordnerbasiert arbeitet.

Das tun die wenigsten, das ist kein Grund.
Es gibt auch keinen Grund, die Nomenklatur zu aendern.
Halt, Moment, ist das Unternehmen nicht in den USA gemeldet? Gut, dann kann es ein Patentproblem sein.

Wenn ich Opera auch als Mailclient vertreiben will, sind damit allerdings auch weitere Schwierigkeiten verbunden, hoechstwahrscheinlich auch Kosten.

»»  *Das* steht aber groß und breit in der Dokumentation.

Opera liefert keine mit. Ich habe zumindest keine mitbekommen. Die ist Online zu haben? Ist fuer mich mit einem 56k-Modem und Minutenabrechnung nicht akzeptabel. Es gibt auch keinen vernuenftigen Grund, warum die nicht mitgeliefert wurde.

Sollte es uebrigens nicht klar geworden sein: ich spiele immer noch mit dem Gedanken statt des Mozillas Opera zu vertreiben, trotz der damit verbundenen Umstellungskosten, denn der Aerger mit Mozilla hat mich schon mindestens 5 Jahre meines Lebens gekostet. Es lohnt sich bei dem derzeitigem Entwicklungsstadium von Opera jedoch nur, wenn Opera eine Preis dafuer nennen kann, das sie die Verantwortung fuer ihr Produkt voll uebernimmt. Die Qualitaet ihres Produktes unterscheidet sich ja mittlerweile nicht mehr wesentlich von der des Mozillas.

Falls also jemand Erfahrung im geschaeftlichem Umgang mit denen hat bitte ich herzlichst um Veroeffentlichung.
Ich koennte natuerlich auch ganz dreist in derem eigenem Forum nachfragen ;-)

so short

Christoph Zurnieden

[molily]

Hallo,

»If the request returns the cached page« - damit kann nur 304 gemeint sein.

Ein 304 hat keinen Messagebody ("MUST NOT" steht in der RFC), der gibt also keine Seite zurueck.

Ja, die Formulierung im Changelog ist Quark, natürlich gibt der Server bei 304 keine Seite zurück. Es kann aber wie gesagt nur 304 gemeint sein, denn genau dieses Verhalten hat sich geändert.

Eine einzige ver!#@*&te Zeile in der Dokumentation haette doch gereicht, warum etwas aendern?

Weil viele Scripte einfach XMLHttpRequest.status == 200 prüfen, weil sie dieses Verhalten vom Browser erwarten.

Was hat denn der Browser, also der Client mit den Statuscodes am Hut, die der Server auswirft?

Äh, was meinst du jetzt? Scripte, die XMLHttpRequest nutzen, fragen eben die gelegentlich die status-Eigenschaft ab. Und da denken die wenigsten JavaScript-Programmierer an 304. Daher hat Opera sein Verhalten dem MSIE und Firefox angeglichen (auch wenn ich Operas voriges Verhalten bzw. Konquerors aktuelles Verhalten für korrekter halte).

Das ist aber auch recht typisch fuer kommerzielle Software. Die muessen verkaufen und richten sich daher streng nach dem Kunden, nicht unbedingt streng nach den Standards, wenn dies die Kunden nicht tun/verlangen.

Ich wiederhole mich:
1. Es gibt keinen Standard, der explizit das eine oder das andere Verhalten fordert.
2. XMLHttpRequest.status == 304 ist eindeutiger und aussagekrätiger, denn man weiß, dass ein Request abgesetzt wurde. Das ist z.B. nützlich für die genannte »Watchdog-Funktion«. Das geht mit MSIE, Firefox und neueren Operas nicht mehr, da muss man die Information in der Ressource selbst unterbringen und müsste in der JavaScript-Anwendung Timestamps vergleichen.

Man kann sich darüber streiten, welches Verhalten sinniger ist. Auf jeden Fall haben beide nichts mit strenger Standardimplementierung zu tun, genausowenig ist eine Methode prinzipiell weniger kundenorientiert als die andere.

Ist aber durchaus in Ordnung, wenn dieses Verhalten auch ordentlich dokumentiert wird. Wenn die ihren Satz aus dem ChangeLog so formulieren, das er auch verstaendlich wird, waere diese Bedingung ja schon erfuellt.

Hehe, ja.

*Das* steht aber groß und breit in der Dokumentation.

Opera liefert keine mit. Ich habe zumindest keine mitbekommen.

Ja, nicht mehr.

Die ist Online zu haben?

Ja, F1 drücken oder im Menü Help > Opera Help.
Ich bekomme dann z.B. http://help.opera.com/Linux/8.5/en/index.html.

Ist fuer mich mit einem 56k-Modem und Minutenabrechnung nicht akzeptabel.

Dann lad sie dir herunter, sind mit wget knapp 216 Kb in 33 Dateien.

Mathias

[Christoph Zurnieden]

Hi,

Weil viele Scripte einfach XMLHttpRequest.status == 200 prüfen, weil sie dieses Verhalten vom Browser erwarten.

Was hat denn der Browser, also der Client mit den Statuscodes am Hut, die der Server auswirft?

Äh, was meinst du jetzt?

Genau das, was ich schrieb.
Ja, gut, ich korrigiere: ausnahmsweise genau das, was ich schrieb.

Scripte, die XMLHttpRequest nutzen, fragen eben die gelegentlich die status-Eigenschaft ab. Und da denken die wenigsten JavaScript-Programmierer an 304.

Ja, ich darf mich da wohl auch drunterzaehlen. Aendert aber rein gar nichts an der Ursache: ein unverlangtes "conditional GET" erzeugte ordnungsgemaess(!) ein 304, das ich vergessen hatte zu beruecksichtigen.
Die ordnungsgemaesse Reparatur haette also darin bestanden, das unverlangte "conditional GET" rauszuschmeissen und stattdessen zu tun, was der Programmierer gesagt hat.

Daher hat Opera sein Verhalten dem MSIE und Firefox angeglichen (auch wenn ich Operas voriges Verhalten bzw. Konquerors aktuelles Verhalten für korrekter halte).

Nein, Opera hat sein Verhalten den Kundenwuenschen angepasst.
Dagegen ist erstmal auch prinzipiell nichts zu sagen, es handelt sich ja schliesslich um kommerzielle Software.
Deshalb sind Konqueror und Firefox hier schlechte Beispiele, da es sich bei denen um OpenSource Software handelt, da kann und darf ich das Verhalten aendern, wenn es mir nicht passt. Da meine Kunden meist ein Komplettpaket wollen, muss ich auch einen Browser anbieten, d.h. ich aendere das Vehalten, hier des Mozillas tatsaechlich.

Das ist aber auch recht typisch fuer kommerzielle Software. Die muessen verkaufen und richten sich daher streng nach dem Kunden, nicht unbedingt streng nach den Standards, wenn dies die Kunden nicht tun/verlangen.

Ich wiederhole mich:

1. Es gibt keinen Standard, der explizit das eine oder das andere Verhalten fordert.

Das war jetzt ganz allgemein formuliert, ich hatte da nichts spezielles im Auge.
Und ein RFC ist zwar kein regulaerer Standard aber immerhin einer de facto, oder?

Die ist Online zu haben?

Ja, F1 drücken oder im Menü Help > Opera Help.

Ich dachte eigentlich, das es eindeutig als rhetorische Frage zu erkennen ist?
Ich bitte um Entschuldigung.

Ist fuer mich mit einem 56k-Modem und Minutenabrechnung nicht akzeptabel.

Dann lad sie dir herunter, sind mit wget knapp 216 Kb in 33 Dateien.

So wenig? Dann haetten sie's ja auch mit beipacken koennen, oder?

so short

Christoph Zurnieden

[at]

Hallo.

Falls also jemand Erfahrung im geschaeftlichem Umgang mit denen hat bitte ich herzlichst um Veroeffentlichung.

Das Gegenteil wäre ratsam, nämlich Opera vor potentiellen Kunden wie dir zu warnen. Ein Verweis auf diesen Thread sollte dafür ja genügen.
MfG, at

[Christoph Zurnieden]

Hi,

Falls also jemand Erfahrung im geschaeftlichem Umgang mit denen hat bitte ich herzlichst um Veroeffentlichung.

Das Gegenteil wäre ratsam, nämlich Opera vor potentiellen Kunden wie dir zu warnen. Ein Verweis auf diesen Thread sollte dafür ja genügen.

Warum? Weil ich die Chuzpe besitze an kommerzielle Software die gleichen Ansprueche wie an alle anderen kommerziellen Produkte auch zu stellen?
Oder weil ich ihre Gratiswarenprobe oeffentlich bemaekele?
Oder weil ich vorher wissen will, wie der Hersteller seine Kunden behandelt?
Oder weil ich vermute, das das Forum auf der Seite des Herstellers nicht ... aeh ... ganz neutral sein koente?
Oder weil ich Quelleinsicht kaufen(!) moechte?
Oder weil ich *grasp* angepasste Versionen vertreiben moechte?
Oder ... ?

Genauso wie es mein gutes Recht ist, nicht bei ihnen einzukaufen, ist es auch deren gutes Recht mir nichts zu verkaufen. Tun wir es jedoch gelten fuer uns die gleichen Regeln wie fuer alle anderen auch. Mir ist es unverstaendlich, wo Du da ein Problem siehst.

Oder vertreibst Du Deine eigene Software mit der typischen Microsoft-Lizenz, die sich auf die vier Worte "Zahlen und Schnauze halten" eindampfen laesst und befuerchtest nun, das mein Beispiel Schule machen koennte?

Oder hast Du Angst, wenn schon nicht vor den etwas arg weitgefassten Ideen Howard Schmidts so doch vor den Konsequenzen der leider recht praezisen Analyse Bruce Schneiers?

Oder hat Dich lediglich das zusaetzliche Glaeschen um 5:03 Streit suchen lassen?

so short

Christoph Zurnieden

[at]

Hallo.

Genauso wie es mein gutes Recht ist, nicht bei ihnen einzukaufen, ist es auch deren gutes Recht mir nichts zu verkaufen. Tun wir es jedoch gelten fuer uns die gleichen Regeln wie fuer alle anderen auch. Mir ist es unverstaendlich, wo Du da ein Problem siehst.

In der Tatsache, dass du davon ausgehst, du hättest eine kostenlose Software käuflich erworben oder sie sei nicht kostenlos, weil sie dich Lernaufwand kostet. Weiterhin in der Tatsache, dass du Fehler bemängelst, die dir im Prinzip schon so lange bekannt sind, dass du bereits Literatur zum Thema herausgesucht hast, und dennoch nicht auf den Erwerb dieser erwiesenermaßen permanent fehlerhaften Produkte verzichtest und so gleichzeitig dieses Prinzip förderst und dich gleichzeitig jeder Glaubwürdigkeit als Opfer beraubst. Von der Lächerlichkeit einiger vermeintlicher Fehler will ja gar nicht sprechen, etwa von nicht mitgelieferten, sondern aus nachvollziehbaren Gründen online vorgehaltenen Hilfe-Dokumenten. Und natürlich in der Tatsache, dass du gleiches Recht für alle einforderst, obwohl hier prinzipiell Vertragsfreiheit besteht.

Oder vertreibst Du Deine eigene Software mit der typischen Microsoft-Lizenz, die sich auf die vier Worte "Zahlen und Schnauze halten" eindampfen laesst und befuerchtest nun, das mein Beispiel Schule machen koennte?

Nein, Gemecker gab es schon immer und wird es vermutlich immer geben. Ich hatte nur darauf verwiesen, dass man sich seine Kunden aussuchen sollte, wenn man die Möglichkeit dazu hat.

Oder hast Du Angst, wenn schon nicht vor den etwas arg weitgefassten Ideen Howard Schmidts so doch vor den Konsequenzen der leider recht praezisen Analyse Bruce Schneiers?

Weder noch. Weder haben die Aussagen nennenswerte Konsequenzen, noch sind sie präzise. Im Gegenteil -- leider, denn der Ansatz ist ja lobenswert.

Oder hat Dich lediglich das zusaetzliche Glaeschen um 5:03 Streit suchen lassen?

Streit ist hier wohl tatsächlich nur mit einem "zusätzlichen Gläschen", vulgo: Lupe, zu suchen.
MfG, at

[Christoph Zurnieden]

Hi,

Genauso wie es mein gutes Recht ist, nicht bei ihnen einzukaufen, ist es auch deren gutes Recht mir nichts zu verkaufen. Tun wir es jedoch gelten fuer uns die gleichen Regeln wie fuer alle anderen auch. Mir ist es unverstaendlich, wo Du da ein Problem siehst.

In der Tatsache, dass du davon ausgehst, du hättest eine kostenlose Software käuflich erworben oder sie sei nicht kostenlos, weil sie dich Lernaufwand kostet.

Das tat ich selbstverstaendlich nicht, denn warum sollte ich die Argumente der Opensourcegegner benutzen?

Du missachtest die Tatsache, das es sich beim Operabrowser um kommerzielle Software handelt. Lediglich der Kaufpreis betraegt 0 Waehrungseinheiten, alles andere ist gleich. Manches ist durch den Kaufpreis bedingt de facto unwirksam, z.B. die Gewaehrleistung. Eine der moeglichen Loesungen bei Eintritt der gesetzlichen Gewaehrleistung ist die Rueckabwicklung des Kaufes und damit die Rueckerstattung des Kaufpreises. Der hat jedoch die Hoehe Null.
Das stoert aber alles nicht die gesetzlichen Rechte und Pflichten der Beteiligten. Darunter zaehlt z.B. auch die Haftung.
Wenn jemand Produkte gratis verteilt und sie schaedigen bei ordnungsgemaesser Anwendung den Nutzer, dann ist der Hersteller dran, da schuetzt ihn kein Vertrag vor. Warum sollte das fuer Software nicht gelten?

Weiterhin in der Tatsache, dass du Fehler bemängelst, die dir im Prinzip schon so lange bekannt sind, dass du bereits Literatur zum Thema herausgesucht hast, und dennoch nicht auf den Erwerb dieser erwiesenermaßen permanent fehlerhaften Produkte verzichtest und so gleichzeitig dieses Prinzip förderst und dich gleichzeitig jeder Glaubwürdigkeit als Opfer beraubst.

Ich moechte keine fehlerhaftes Produkt erwerben sondern ein fehlerfreies. Deshalb stelle ich die Fehler fest. Teilweise belege ich das auch durch Literatur, die das gleiche tut: Fehler feststellen. Was ist daran verkehrt?
Wenn ich ein Auto kaufen moechte, das prinzipiell mit fehlerhaften Spiegeln ausgeliefert wird, das mir aber im grossem und ganzem gefaellt, dann versuche ich einen Weg zu finden, wie ich dem Problem der beschaedigten Spiegel entgegne. Diese Wege koennen verschiedenster Art sein, aber im Gegensatz zum Auto ist es bei Software keinem Drittanbieter moeglich Ersatzspiegel anzubieten solange der Hersteller die alten Spiegel nicht austauschbar anbringt.

Deswegen rege ich mich beim Mozilla ueber Fehler nicht auf, ich repariere sie einfach. Ich rege mich jedoch ueber die Handhabung der Blaupausen und Fehlerberichte durch die Mozilla-Entwickler auf.
Beim Opera kann ich nichts selber reparieren, zumindest nicht mit vertretbarem Aufwand. Es bleibt also nur die Moeglichkeit, den Hersteller dies tun zu lassen. Der ist wiederum kommerziell, richtet sich nach seinen Kunden. Wenn die in Mehrheit mit dem Fehler leben koennen, hat Opera keinen vernuenftigen Grund den Fehler zu reparieren. Moechte ich ihn fuer mich repariert haben oder das Produkt sonstwie veraendert haben muss ich Opera dazu ueberreden. Das funktioniert bei Firmen hervorragend, wenn man ordentliche Mengen konvertible Waehrung anbietet. Offene Fragen sind demnach: was wird Opera selbst reparieren und wie teuer, schnell und gut sind die bei Auftragsarbeiten. Es ist jedoch _keine_ Frage, ob sie ueberhaupt zu allem bereit sind, denn bei genuegendem Einsatz von Geld kann ich die Firma ja uebernehmen (was nicht immer legal ist, aber ich wollt's fuer Dich nicht unnoetig kompliziert machen).

Hier ist also niemand Opfer und somit auch niemand Taeter.

Von der Lächerlichkeit einiger vermeintlicher Fehler will ja gar nicht sprechen, etwa von nicht mitgelieferten, sondern aus nachvollziehbaren Gründen online vorgehaltenen Hilfe-Dokumenten.

Die Gruende sind fuer mich nicht nachvollziehbar, moechtest Du das uebernehmen?
Fehlende Dokumentation ist uebrigens nach EU-Recht ein Mangel.

Und natürlich in der Tatsache, dass du gleiches Recht für alle einforderst, obwohl hier prinzipiell Vertragsfreiheit besteht.

Die Vertragsfreiheit (die es so seit Manchesterzeiten gottseidank nicht mehr gibt) basiert aber darauf, das das Recht fuer alle gleich ist, niemand ist "gleicher".

Oder vertreibst Du Deine eigene Software mit der typischen Microsoft-Lizenz, die sich auf die vier Worte "Zahlen und Schnauze halten" eindampfen laesst und befuerchtest nun, das mein Beispiel Schule machen koennte?

Nein, Gemecker gab es schon immer und wird es vermutlich immer geben. Ich hatte nur darauf verwiesen, dass man sich seine Kunden aussuchen sollte, wenn man die Möglichkeit dazu hat.

Dsa Recht habe ich allen Beteiligten gleich im erstem Satz eingeraeumt:"Genauso wie es mein gutes Recht ist, nicht bei ihnen einzukaufen, ist es auch deren gutes Recht mir nichts zu verkaufen."
Schwierig wird's natuerlich bei Monopolisten, die ihre Position auf illegale Weise ausnutzen, wie es z.B. die Firma Microsoft getan hat und teilweise auch heute noch tut.

Oder hast Du Angst, wenn schon nicht vor den etwas arg weitgefassten Ideen Howard Schmidts so doch vor den Konsequenzen der leider recht praezisen Analyse Bruce Schneiers?

Weder noch. Weder haben die Aussagen nennenswerte Konsequenzen, noch sind sie präzise. Im Gegenteil -- leider, denn der Ansatz ist ja lobenswert.

Wieso meinst Du denn, das der Ansatz lobenswert ist, wo der gleiche Ansatz von Dir verdammt wird, nur weil ich ihn ausgesprochen habe?

so short

Christoph Zurnieden

[at]

Hallo.

Genauso wie es mein gutes Recht ist, nicht bei ihnen einzukaufen, ist es auch deren gutes Recht mir nichts zu verkaufen. Tun wir es jedoch gelten fuer uns die gleichen Regeln wie fuer alle anderen auch. Mir ist es unverstaendlich, wo Du da ein Problem siehst.

In der Tatsache, dass du davon ausgehst, du hättest eine kostenlose Software käuflich erworben oder sie sei nicht kostenlos, weil sie dich Lernaufwand kostet.

Das tat ich selbstverstaendlich nicht, denn warum sollte ich die Argumente der Opensourcegegner benutzen?

Weshalb, weiß ich auch nicht. Daher ja meine Beschwerde darüber.

Du missachtest die Tatsache, das es sich beim Operabrowser um kommerzielle Software handelt.

Nein.

Weiterhin in der Tatsache, dass du Fehler bemängelst, die dir im Prinzip schon so lange bekannt sind, dass du bereits Literatur zum Thema herausgesucht hast, und dennoch nicht auf den Erwerb dieser erwiesenermaßen permanent fehlerhaften Produkte verzichtest und so gleichzeitig dieses Prinzip förderst und dich gleichzeitig jeder Glaubwürdigkeit als Opfer beraubst.

Ich moechte keine fehlerhaftes Produkt erwerben sondern ein fehlerfreies.

Dann tue das doch.

Deswegen rege ich mich beim Mozilla ueber Fehler nicht auf, ich repariere sie einfach. Ich rege mich jedoch ueber die Handhabung der Blaupausen und Fehlerberichte durch die Mozilla-Entwickler auf.

Auch das halte ich für absolut überflüssig.

Beim Opera kann ich nichts selber reparieren, zumindest nicht mit vertretbarem Aufwand. Es bleibt also nur die Moeglichkeit, den Hersteller dies tun zu lassen. Der ist wiederum kommerziell, richtet sich nach seinen Kunden. Wenn die in Mehrheit mit dem Fehler leben koennen, hat Opera keinen vernuenftigen Grund den Fehler zu reparieren. Moechte ich ihn fuer mich repariert haben oder das Produkt sonstwie veraendert haben muss ich Opera dazu ueberreden.

Oder davon überzeugen. Diese Diskussion ist dahingehend allerdings wenig zielführend -- wie gesagt.

Hier ist also niemand Opfer und somit auch niemand Taeter.

Dann muss sich ja auch niemand beschweren.

Von der Lächerlichkeit einiger vermeintlicher Fehler will ja gar nicht sprechen, etwa von nicht mitgelieferten, sondern aus nachvollziehbaren Gründen online vorgehaltenen Hilfe-Dokumenten.

Die Gruende sind fuer mich nicht nachvollziehbar, moechtest Du das uebernehmen?

Ja, ich vollziehe sie gern nach.

Fehlende Dokumentation ist uebrigens nach EU-Recht ein Mangel.

Sie fehlt ja nicht, sondern wird lediglich nicht mitgeliefert.

Die Vertragsfreiheit (die es so seit Manchesterzeiten gottseidank nicht mehr gibt) basiert aber darauf, das das Recht fuer alle gleich ist, niemand ist "gleicher".

Dann empfehle ich dir, diesen Unfug anderswo zu publizieren und dessen Halbwert zu messen.

Oder vertreibst Du Deine eigene Software mit der typischen Microsoft-Lizenz, die sich auf die vier Worte "Zahlen und Schnauze halten" eindampfen laesst und befuerchtest nun, das mein Beispiel Schule machen koennte?

Nein, Gemecker gab es schon immer und wird es vermutlich immer geben. Ich hatte nur darauf verwiesen, dass man sich seine Kunden aussuchen sollte, wenn man die Möglichkeit dazu hat.

Dsa Recht habe ich allen Beteiligten gleich im erstem Satz eingeraeumt:"Genauso wie es mein gutes Recht ist, nicht bei ihnen einzukaufen, ist es auch deren gutes Recht mir nichts zu verkaufen."

Es war ja auch nur eine Antwort auf deine Frage.

Schwierig wird's natuerlich bei Monopolisten, die ihre Position auf illegale Weise ausnutzen, wie es z.B. die Firma Microsoft getan hat und teilweise auch heute noch tut.

Das regelt die Zeit. Microsoft lebt von politischen Entscheidungen, und die hinken den technischen und sozialen Realitäten eben immer etwa zehn Jahre hinterher.

Oder hast Du Angst, wenn schon nicht vor den etwas arg weitgefassten Ideen Howard Schmidts so doch vor den Konsequenzen der leider recht praezisen Analyse Bruce Schneiers?

Weder noch. Weder haben die Aussagen nennenswerte Konsequenzen, noch sind sie präzise. Im Gegenteil -- leider, denn der Ansatz ist ja lobenswert.

Wieso meinst Du denn, das der Ansatz lobenswert ist, wo der gleiche Ansatz von Dir verdammt wird, nur weil ich ihn ausgesprochen habe?

Weil du weißt, was dich erwartet, wenn du Software erwirbst oder einsetzt. Einen arglosen Nutzer hingegen könnte eine solche Regelung wirksam schützen. -- Dass die Forderung letztlich utopisch ist, ist ja ein anderes Thema.
MfG, at

[Raik]

Hallo, Marco!

// Mozilla, Opera und Safari
  if (!xmlHttp  && typeof XMLHttpRequest != 'undefined')
  {
    xmlHttp = new XMLHttpRequest();
  }
  if (xmlHttp)
  {
    xmlHttp.open('GET', Dateiname, true);
    xmlHttp.onreadystatechange = function ()

"onreadystatechange" gibts beim mozilla/firefox nicht,
da heist das ganz simpel "onload".

{

. »       if (xmlHttp.readyState == 4)
. »       {

Inhalt = xmlHttp.responseText;

. »       }

};
    xmlHttp.send(null);
  }
  return Inhalt;
}

die zeilen ". » " fallen beim mozilla weg.

freundl. Grüsse aus Berlin, Raik

[Thomas Meinike]

Hallo,

"onreadystatechange" gibts beim mozilla/firefox nicht,
da heist das ganz simpel "onload".

onload existiert, aber onreadystatechange ist zumindest in den aktuellen Firefox-Versionen ebenfalls vorhanden.

{
. »       if (xmlHttp.readyState == 4)
. »       {
        Inhalt = xmlHttp.responseText;
. »       }
    };
    xmlHttp.send(null);
  }
  return Inhalt;
}

die zeilen ". » " fallen beim mozilla weg.

Bei welchen Versionen? Auch Firefox kennt die Eigenschaft readyState. Lediglich bei der Initialisierung eines XMLHttpRequest-Objektes muss man eine Unterscheidung treffen. Der Rest verlaeuft erfreulicherweise in gleicher Art und Weise ab.

AFAIK ist die Methode overrideMimeType() noch Mozilla/FF-spezifisch.

MfG, Thomas

[Raik]

Hallo, Thomas!

onload existiert, aber onreadystatechange ist zumindest in den aktuellen Firefox-Versionen ebenfalls vorhanden.

komisch, ich hab mit firefox 1.07 getestet und hatte da probleme.
wird das offizieller standard?
wozu könnte die unterscheidung der readyState's gebraucht werden? ist nicht "4" der einzig interessante?

Auch Firefox kennt die Eigenschaft readyState. Lediglich bei der Initialisierung eines XMLHttpRequest-Objektes muss man eine Unterscheidung treffen. Der Rest verlaeuft erfreulicherweise in gleicher Art und Weise ab.

danke für den link! :-)

freundl. Grüsse aus Berlin, Raik

[Raik]

Hallo, Thomas!

komisch, ich hab mit firefox 1.07 getestet und hatte da probleme.

unterschied gefunden:
wenn ich mit "load()" arbeite statt mit XMLHttpRequest, gibts auch keine readyState's. ;-)

freundl. Grüsse aus Berlin, Raik

[Raik]

Hallo,

wozu könnte die unterscheidung der readyState's gebraucht werden? ist nicht "4" der einzig interessante?

da das anscheinend etwas untergegangen ist, nochmal die frage:
was kann man mit den readyState's 1-3 anfangen? haben die irgend einen praktischen nutzen?
oder ist die "4" nicht die einzig interessante?
gut, bei einem langsamen server und grossen dateien kann man evtl. statusinformationen ausgeben, um sich die zeit zu vertreiben, aber gibts da auch was wirklich nützliches?

freundl. Grüsse aus Berlin, Raik

[Tim Tepaße]

Hallo Raik,

was kann man mit den readyState's 1-3 anfangen? haben die irgend einen praktischen nutzen?

Laut der „reinen Theorie“ lauten die readyStates ja so:

0 (Initialized) - Objekt existiert, open() noch nicht aufgerufen.
1 (Loading)     - open() aufgerufen, aber send() noch nicht aufgerufen
2 (Loaded)      - send() aufgerufen
3 (Interactice) - Daten kommen langsam rein, man könnte schon den responseText abfragen
4 (Complete)    - Alles fertig.

Das geschieht auch so ungefähr in den Browsern, auch wenn diese sich noch uneinig darüber scheinen, wann das Event onreadystatechange feuern muss, wie Peter-Paul Koch die Tage in seinem Quirksblog ausführlich beschreibt.

Wofür sind nun die einzelnen readyStates gut? Mal in zeitlich umgekehrter Reihenfolge:

readyState 4 ist natürlich klar.

readyState 3 ermöglicht einen, schonmal auf Daten zu zugreifen, ohne dass man darauf warten muss, dass versucht wurde, aus der vermeintlichen XML einen DOM-Baum zu parsen. Gut für Byteströme, z.B. reinen Text.

readyState 2 ermöglicht einen, schon mal auf Status-Code und Status-Text des HTTP-Requests zu zugreifen, jedenfalls meiner Erfahrung nach (1). Dies ist zum Beispiel praktisch, wenn es um ungewöhnlichere Status-Codes geht. Dies können selbstgemachte Fehlercodes sein, die die HTTP Spezifikation erlaubt, das kann aber auch ein simpler 304 Not Modified beim Cachen sein. Bei größeren Dokumenten, die dann nicht noch mal eingelesen werden sollen, wäre es vielleicht sinnvoll schon bei diesem readyState und bei diesem HTTP Status abort() aufzurufen.

readyState 1 ist mir selber ein Mysterium. Alles war ich mir vorstellen kann, wäre höchstens eine Art introspektive Automatisierung des Requests, wenn open() aufgerufen wird wird automatisch noch einiges zur Konfiguration, wie die Setzung von Headern oder ganz witzig, der automatische Aufruf von send(). Vielleicht sinnvoll, wenn man aus irgendwelchen Gründen nur eine Methode (open) Aufrufen kann, allerdings kann ich mir keinerlei Einsatzzweck vorstellen.

readyState 0 dürfte klar sein.

(1) Meine Erfahrungen: Ich kann das natürlich nicht verallgemeinern, aber meinen Tests zufolge tritt immer dieser Reihenfolge auf, sowohl bei kleinen, als auch bei sehr großen zu ladenden Dokumenten. Natürlich ist es schwierig, so etwas in einem asynchronen Modell zu „messen“, auf komplexere Messmechanismen hatte ich damals keine Lust, deswegen hatte ich nur eine sehr simple „Messmethode“. Und dazu kommen dann noch die Problemchen mit dem in diversen Browser unterschiedlich feuernden Event, wie oben bei Quirksmode geschildert.

gut, bei einem langsamen server und grossen dateien kann man evtl. statusinformationen ausgeben, um sich die zeit zu vertreiben, aber gibts da auch was wirklich nützliches?

Oh, aus dem Gesichtspunkt der Softwareergonomie ist eine Rückmeldung, dass etwas passiert sehr nützlich. Und wenn es nur eine Sanduhr, bzw. ein Sat1-Ball ist. ;) Soll heißen: Wenn es zwischen 0 und 4 nicht noch mindestens einen readyState gegeben hätte, wäre das doch recht doof gewesen.

Tim

[Raik]

Hallo, Tim!

... das kann aber auch ein simpler 304 Not Modified beim Cachen sein. Bei größeren Dokumenten, die dann nicht noch mal eingelesen werden sollen, wäre es vielleicht sinnvoll schon bei diesem readyState und bei diesem HTTP Status abort() aufzurufen.

das würde ich dann ehr über das setzen von If-Modified-Since: oder If-None-Match: (ETag) lösen. dann versucht der server im entsprechenden fall garnicht erst, etwas zusenden.

... deswegen hatte ich nur eine sehr simple „Messmethode“.

die seite wird immer neu geladen, so dass man das ergebnis nur kurz sieht.

Wenn es zwischen 0 und 4 nicht noch mindestens einen readyState gegeben hätte, wäre das doch recht doof gewesen.

wenn man content-length auswertet und mit intervall die buffer.length bestimmt, kann man ja evtl. nen fortschrittsbalken bauen?

freundl. Grüsse aus Berlin, Raik

[Christoph Zurnieden]

Hi,

readyState 1 ist mir selber ein Mysterium. Alles war ich mir vorstellen kann, wäre höchstens eine Art introspektive Automatisierung des Requests, wenn open() aufgerufen wird wird automatisch noch einiges zur Konfiguration, wie die Setzung von Headern oder ganz witzig, der automatische Aufruf von send(). Vielleicht sinnvoll, wenn man aus irgendwelchen Gründen nur eine Methode (open) Aufrufen kann, allerdings kann ich mir keinerlei Einsatzzweck vorstellen.

Du kannst da schon abort() aufrufen und es ist noch nichts zum Server gesendet worden. Wenn Du z.B. in einem INPUT jeden Buchstaben auf dem Server abfragst (Googles Vorschlagswesen waere da ein Beispiel) kann in der Zwischenzeit mehreres passieren: nichts, ein oder mehrere Buchstaben kommen hinzu, ein oder mehrere Buchstaben werden geloescht. In den beiden letzten Faellen wuerde es dem Server Arbeit und allen Transferkosten ersparen, wenn die Anfrage gleich abgebrochen und geaendert abgeschickt wird. readyState 1 ist zwar also nicht wirklich zwingend noetig, aber, wie Du auch schon richtig vermutet hast hauptsaechlich der Vollstaendigkeit halber drin.

so short

Christoph Zurnieden