[Seeky] Draft

[Julian Ganz]

Hi, alle, die hier noch mitlesen.

Eine Nachricht auf der CCC-Debattier-Liste hat mich dazu bewegt,
bisherige Gedanken bzw Projekt-Outlines zu posten. Eine ähnliche Mail
wird wohl demnächst von Niels zu erwarten sein. Wenn diese gepostet ist,
kann man vergleichen bzw diskutieren und zu einem Arbeits-Modell
übergehen.


1) Protokoll (Daten):
Die Software muss verschiedene (genau 2) Arten von Daten handhaben
können, darunter:

1.1) Anfragen
Anfragen können unterschiedlich ausfallen, es gibt:
1.1.1) Kapabilitäts-Anfragen:
Selbsterklärend, liefert eine liste von Stichworten bzw IDs.
1.1.2) Roh-Daten-Anfragen:
Fragt Roh-Daten ab, nützlich zB für Crawler oder Indexer, die diese
Daten sammeln. Antworten werden im üblichen, aber ausfühlichen
Antwort-Format geliefert (1.2.2)
1.1.3) Such-Anfragen:
Such-Anfragen sollten unterschiedlich eingegeben werden können, aber vom
Client in ein globel verständliches Format umgewandelt werden. Diese
Anfragen sollten mE zwei Teile enthalten:
1.1.3.1) Target-Spezifier:
In dem spezifiziert wird, was gesucht wird (Text, *.tar-Archive, nur
Metadaten, Index-Listen, Nodes, ...) und durch welche Protokolle diese
Daten ggf. erreichbar sein müssen (http, ftp, bittorrent, local, ...).
1.1.3.2) Such-Ausdruck (bei einigen anfragen Optional):
Diese sollten als Ausdrucks-Baum aus Verknüpfungen (AND,OR,NOT,...) und
Tokens (Suchbegriffe, Hashes, Vergleich-IDs -Sichtwort Music Brainz,
Bildvergleich) aufgebaut sein.
Möglich wäre es, diese Ausdrücke wie in diversen Programmiersprachen
duch Operatoren in Form einzelner Zeichen und kurzer Strings, Klammern
und Tokens in String-Form auszudrücken. Tokens ließen sich syntaktisch
leicht und Portabel durch eine einfache Syntax unterscheiden. Einfache
Such-Strings ließen sich so durch Double-Quotes kennzeichnen, Hashes zB
durch Konstrukte wie "with(md5=...,anderer_wert=...)". Was der Server
nicht kennt, kann er dann ignorieren.

1.2) Antworten
Antworten bestehen natürlicher Weise aus Listen mit URIs, aber auch aus
einem (evtl optionalen) "Globalen" Teil (dieser enthält zB
Wort-Index-Zuweisungen für platzsparendere Übertragungen) und
"Seriellen" Teilen.
Man bemerke hier, dass im Falle eines crawl-freudigen Clients wohl
"Antworten" an Server gesendet werden, zu denen es keine explizite
"Anfrage" gegeben hat.
1.2.1) Globaler Datensatz:
Der globale Teil muss hier immer zuerst gesendet werden, um den
nachvolgenden Datenschwall sinnvoll verarbeiten zu können. (mir ist
klar, dass das durch nötiges Caching evtl eine mehr-Belastung für den
Sender bringt, aber besser für ihn als für den Empfänger). Es wäre
denkbar, in einem Datenstrom einen "neuen" Globalen Datensatz zu senden,
der dann auf nachfolgende Serielle Datensätze angewendet wird.
1.2.2) Serielle Datensätze:
Diese enthalten jeweils eine URI und optional Scoring-Informationen,
sowie je nach Anfrage Roh-Daten, wie Listen enthaltener Wörter.
Bei einigen Such-Anfragen ist eine URI nicht einmal zwingend nötig oder
nicht sinnvoll, sondern einzig Metadaten.



2) Serialisierung:
Was die Serialisierungsmethode angeht, sollte man sich mE nicht auf eine
einzige festlegen, sondern jeweils eine Text-Basiierte (für Erzeugung
durch PHP-Scripte etc.) und eine Binäre Variante verfolgen. Wichtig ist
nur, dass beide Varinten sich zu ein und dem selben konstrukt
De-Serialisieren lassen und dass beide Tollerant gegenüber dem Client
unbekannten Einträgen sind.
Evtl lassen sich hier Serialisierungs-Methoden zB aus der Boost-Library
nutzen. (Hauptsache standarisiert und transparent)

2.1) XML:
Vor allem interessant für den Web-Bereich, sei es ein PHP-Script, dass
als Server dient, statisch abgelegte Index-Listen oder Java-Scripte, die
XML Parsen und daraus eine Liste auf einer Benutzer-Oberfläche erzeugen.

2.2) Binär/UDP:
Interessant ist es, UDP für Client-Programme, die direkt installiert
werden, zu benutzen da sich Anfragen in einem einzigen Paket verschicken
lassen. Bei Antworten ist es zudem Irrelevant, ob die Liste in einem
Stück ankommt oder nicht, so lange die einzelnen "Seriellen" Datensätze
intakt sind.
2.2.1) Header:
Speziell bei UDP sollte dem Daten-Teil ein Header vorgeschaltet sein,
der einige Metadaten, wie Checksumme, Such-ID (Evtl einfach ein Hash der
Anfrage) und HOPs (siehe 3.2) beinhaltet.

2.3) Crypto:
Hauptsächlich sinnvoll für Such-Anfragen. Bei HTTP wäre dies eifnach
über HTTPS realisierbar, bei UDP-Kommunikation könnte man übe den Header
zB im Vorraus Öffentliche Sende- und Empfangs-Schlüssel beantragen.


3) Transport:
Es sollte verschiedene Möglichkeiten geben, einen Such-Dienst oder
Crawl-Daten bereit zu stellen. Die Transport-Variante sollte direkt aus
der URI hervorgehen.

3.1) Direkte Verknüpfungen:
Hier sollte man die Binäre/UDP-Variante benutzen.

3.2) Dynamisch/HTTP
Vor allem für kleinere Such-Interfaces und Crawler, die direkt in eine
Web-Umgebung, wie einen internet-Auftritt eingebettet sind, ist es
sinnvoll, einen Standart zu definieren, wie Anfragen über Post/Get
kommuniziert werden. So kann man PHP-/Python-/ASP-Scripte schreiben,
welche sich bei Verdacht auf Interesse gleich nach diversen Dingen
fragen lassen. (evtl wäre es -auch für statisches Crawling beim Host-
sinnvoll, hier irgendwann vorgefertigte Klassen zu schreiben). eine
Text-Basiierte Serialisierung wäre zu bevorzugen, aber dank
Magic-Numbers scheidet binäre Kommunikation nicht aus -sofern beide
Seiten dies unterstützen.

3.3) Statisch
Eine URI zu einem einfachen Dump-File.


4) Netzwerk:
Hier gibt es mehrere Möglichkeiten:

4.1) Direkt-Anfragen:
Die offensichtlichste Methode, eine Suche zu unternehmen oder
Crawl-Ergebnisse los zu werden, ist, eine Anfage bzw die Datensätze an
einen Server zu senden.
Gecrawlte Datensätze können im UDP-Fall einfach dann gesendet werden,
wenn ein UDP-Paket "ausreichend" gefüllt ist. Im XML-Fall müsste man
sich andere "Trigger" einfallen lassen. (trivial)

4.2) P2P:
Es wäre aber auch möglich, einen Server um eine Liste von Nodes zu
bitten, zu der er -evtl neben Keep-Alive-Pings- Anfragen und
Crawl-Ergebnisse senden soll. LANG-IDs wie "de", evtl durch Kommata
kontrahiert (de,en) könnten sicher stellen, dass diese Nodes Ergebnisse
in erwünschten Sprachen überhaupt liefern können -sofern der Server
Nodes mit diesen LANG-IDs kennt. (zusätzlich könnte man Serverseitig
anhand von IP und Hostname sicherstellen, dass diese Nodes auch in der
relativen Nachbarschaft liegen, um sinnlosen Datenverkehr über "zu
viele" Subnetze hinweg einzudämmen). Diese Nodes können auch andere
Server beinhalten.
Wird eine Frage eingegeben, kann der Client dann an jeden Node eine
Anfrage versenden, welche sie -den HOP (wenn zu hoch drastisch)
reduzierend- ohne den Inhalt zu verändern jeweils an die nächsten Nodes
weiterleitet und selbst eine Antwort sendet. Antworten werden -wie die
Anfragen auch- rückwärts weitergeleitet (die anfallenden "Seriellen"
Daten könnte man dann behalten und im Cache speichern).

4.3) IM:
Auf lange Sicht wäre es auch überlegenswert, Plugins zu schreiben, über
welche man Such-Anfragen zusätzlich auch zB. an Jabber/XMPP-Kontakte
sendet. Da die Interessen idR recht nah beieinander liegen (zumindest
meist näher als im Falle wildfremnder Internet-Beutzer), könnte das
recht gute Ergebnisse liefern.


5) Referenzen:
Man sollte sich Gedanken darüber machen, wie Web-Entwicker uns das Leben
leichter machen können, wenn sie wollen ;)

5.1) HTML-Einbettung:
Es sollte ein <rel>-Tag definiert werden, in dem Such-Interfaces oder
Crawl-Dumps angegeben werden können.

5.2) robots.txt:
Auch hier sollte ein Format ausgearbeitet werden.


Die nächsten Tage kommen noch Erläuterungen zu diversen Einzelheiten.
Dass Feedback und evtl auch Fragen erwünscht sind, erklärt sich von
selbst.

Grüße,
Julian Ganz