nicht angemeldet
- hier ist schon lange keiner mehr beschimpft worden.
Schön, wir haben gerade eine friedliche Phase. Das wird auch wieder anders.
Er wurde ledentlich darauf hingewiesen, daß er erst einmal suchen soll, bevor er postet und zu 80% war sogar der Zielführende Link dazu angegeben, falls dieses Thema lang und breit in SELFHTML abgehandelt wurde. Und in SELFHTML gibt es sehr gute Suchfunktionen, überhaupt die Offline-Suche ist einmalig.
Sorry, da sind wir einfach unterschiedlicher Meinung. Es gibt einfach keine Suchmaschine, die *weniger* kann.
Klar, es ist schwer, eine zu schreiben. Aber das ändert nichts daran, daß es unrealistisch ist, die Leute an *diese* Suchfunktion zu verweisen.
Wollen wir nun diese Trivial-Fragen, die man durch Suche hätte lösen können, im Forum haben oder nicht?
Der Rest steht in der Auslese (die ja gar nicht von Stefan gemacht wird) bzw. im Archiv, wobei ich auch schon zum zweiten Punkt komme.
Wer eine Frage beantwortet haben will, der *will* eine Suchfunktion, nicht aber die Auslese komplett durchlesen.
Das Problem ist ja eben, daß der Fragende oftmals gar nicht genug über sein Problem sagen kann, um es hierarchisch korrekt (wie die Auslese erfreulicherweise strukturiert ist) einzuordnen - schau Dir die vielen falschen Klassifizierungen im Forum doch nur an.
Bei einer Suche nach seinen Stichworten wäre die Trefferchance größer. Warum, glaubst Du, gibt es im WWW Suchmaschinen und nicht nur Link-Listen???
- Was ist eine gute Suchfunktion? Wenn jemand nach HTML sucht und CGI meint, dann kann ihm auch das beste Suchsystem nicht helfen!
Einspruch: Wenn er nach HTML *und* Passwortschutz sucht, dann findet er genau die Forum-Postings, in denen dieser Irrtum schon mal aufgeklärt wurde!
In der Forum-Auslese findet er kein Kapitel über Passwortschutz, schon gar nicht in der Abteilung HTML, weil es da eben nichts verloren hat. Und nun?
99% meiner Suchvorgänge im Forum-Archiv lassen sich nicht mit weniger als zwei oder drei Suchbebegriffen beschreiben, wenn ich weniger als 500 Treffer haben will.
Was nützt es mir, wenn ich hunderte oder tausende von Treffern prüfen muß, ob sie mein Problem beschreiben, nur weil die Suchfunktion mir nicht erlaubt, die Treffermenge intelligent einzuschränken?
Und mit wachsender Zahl der Archiv-Einträge wird die Trefferzahl immer höher werden. Ich finde, wir sollten hier perspektivisch denken.
"AND" als Operator würde 90+% aller Suchvorgänge ermöglichen, die bisher einfach keinen Sinn haben. Genau "AND" als Operator und sonst *nichts*. Also z. B. wiederholte Filterdurchgänge pro Dokument - ist das sooo schlimm?
Mehr will ich nicht. Kein OR, kein NEAR, nur AND. Das allein wäre ein Quantensprung! Ich benutze auch bei den großen Suchmaschinen nur selten einen anderen Operator.
Der zweitwichtigste wäre dann übrigens "NOT", dessen Implementierung in Perl durch eine ELSE-Verzweigung zu realisieren wäre. NOT ohne AND macht aber keinen Sinn, deshalb Nummer Zwei.
Und wie Calocybe anmerkte: Ja, ich denke durchaus darüber nach, das selbst einzubauen. Sicherlich könnten es Frank Schönmann oder Cheatah oder Calocybe schneller als ich, aber das ist eben die "Initiativstrafe" für den "Meckerer".
Die Aufgabe wäre übrigens aufteilbar in den Entwurf des erweiterten Suchformulars (möglicherweise möchte man die AND-Funktion abschaltbar haben, falls sie Performance kostet) und die Erweiterung des Perl-Skripts (?, ich kenne die Suchfunktion bisher nicht von innen) an sich.
P.S.: Vielleicht habe ich mich jetzt ein wenig reingesteigert, aber es mußte einmal sein. Also tut leid wenn ich meinen "Ärger" mit dieser Problematik der sich über Monate angestaut hat, jetzt nur an dir ausgelassen habe. Aber denk mal darüber nach!
Das tue ich, wie Du siehst. Laß es nur raus, aber ich finde, Du hast sachlich Unrecht.
Die Suchfunktion ist das erste, woran etwas getan werden muß.
Beispielsweise könnte man darüber diskutieren, ob Stefan eine schreiben soll oder ob man nicht vielleicht besser eine installiert, die es schon gibt - auch das poste ich nicht zum ersten Mal.
Ich habe hier im Büro versuchsweise eine alte Version der Suchmaschine httpGlimpse von der Uni Arizona laufen, die gab es im Perl-Source.
Die sucht nicht etwa die Dokumente durch, sondern sie indext diese (der Job läuft bei mir an jedem Sonntag) und sucht dann im Index.
Das dabei verwendete eigene Systemkommando glimpse (syntaktisch eine Variante von grep) ist sogar so genial, daß es - auf Kosten der Performance - eine einstellbare Abweichung (Hamming-Abstand?) bei der Schreibweise akzeptiert, also auch falsch geschriebene Worte findet! (Das ist das spezielle Forschungsthema der Arizona-Leute, um glimpse herum gibt es eine ganze Familie von Produkten, einige davon sind auch kommerzielle Suchmaschinen.)
Mein altes glimpseHttp kann *kein* AND, wäre also nicht *die* Lösung. Ich wollte damit nur anmerken, daß es PD-Suchmaschinen *gibt* und daß die auch nur mit Wasser kochen (ich habe mal schnell eingebaut, daß im Formular eingegebene Umlaute in ihrer HTML-Form gesucht werden sollen usw. - das Such-Frontend ist gar nicht schwer zu verstehen, der Indexer ist schon eher kryptisch).