nicht angemeldet
Ist natürlich auch psychologisch netter, wenn der User weiß, daß er noch 20 Minuten warten soll, anstatt ihm einfach 20 min lang ein bewegungsloses Bild eines Browsers zu präsentieren - das hält dann garantiert keiner durch <g>.
Ich habe die letzten Tage damit verbracht, so etwas Ähnliches zu entwickeln.
Ganz kurz: Der Anwender startet via CGI einen "Auftrag", welcher auf dem Server-Rechner an einen Warteschlagenverwalter übergeben wird. Dieser synchronisiert dann die Aufträge und startet einen nach dem anderen.
Der Anwender will im Browser aber mitbekommen, wann es wirklich losgeht und was auf dem Server so passiert.
Ich habe als Reaktion auf das abgeschickte Formular via CGI ein Frameset aus zwei Frames generiert, welche jeweils wieder CGI-Calls enthalten.
Im größeren Frame erscheint eine Art Auftragsbeschreibung; via HTTP-Refresh aktiviert dieses CGI sich selbst nochmal mit geänderten Parametern, was einen Wartevorgang von max. 30 Sekunden auslöst, an dessen Ende entweder ein Timeout oder ein HTML-Dokument mit Hyperlinks auf die auf dem Server generierten Dateien steht. (Und
ein button "weiter warten", der den ersten der beiden CGI-Calls nochmal ausführt.)
Im kleineren Frame erscheint ein HTML-Dokument, welches sich via HTTP-Refresh ständig selbst neu läuft (Frequenz wird in Abhängigkeit der Verarbeitungsphase dynamisch berechnet; es ist eine Intranet-Anwendung, ich habe also keine Bandbreitenprobleme; das Dokument ist auch nur 350 bytes groß). Dieses Skript weiß via CGI-Parameter die Namen aller temporären Dateien des Prozesses, kann also in einer Art "Statusleiste" (triviale HTML-Tabelle) jeweils anzeigen, in welcher Verarbeitungsphase der Auftrag ist, wie lange die ganze Sache schon läuft (Startzeit wird via CGI übergeben) und wie groß die aktuelle Datei derzeit ist.
Fazit: "Der Browser lebt." Und alles ohne Server-Push.
Endlich die Klicki-Bunti-Lösung, die die Kunden schon immer haben wollten ... Aber fragt nicht, wie lang die CGI-Parameterlisten sind. :-(