[Seeky] Draft

[Julian Ganz]

On Mon, 7 Mar 2011 13:06:48 +0100
Niels Dettenbach <nd at syndicat.com> wrote:

> Hallo Julian,
> 
> 
> Am Donnerstag 03 März 2011, 01:18:50 schrieb Julian Ganz:
> > 1) Protokoll (Daten):
> > Die Software muss verschiedene (genau 2) Arten von Daten handhaben
> > können, darunter:
> Hierzu am besten mal den aktuellen Stand (wie meine Mail von eben)
> des niedergeschriebenen "Drafts" zu einem SOIF-NG / SOIF2 im Konzept
> lesen.
> 
> Im Prinzip liegst Du mit Deiner Analyse m.E. recht weit richtig,
> allerdings sind dies im SEEKY Konzept verschiedene - definierte / zu
> definierende - Protokolle / Formate - auf verschiedenen "Ebenen".
Wenn aber der Prozess durchgängig auf allen Ebenen Daten fast gleicher
Form erzeugt, die an anderer Stelle gelesen werden, warum dann nicht
alles über ein Protokoll tunneln?
Der MI fragt die PLBs nach Index-Listen (Dumps, einen Datensatz pro
URI) und bekommt eine Liste von diesen.
Der SRE fragt die MIs nach URIs (oder sonstigen Daten) betr einer
Such-Afrage und bekommt eine Liste mit diesen.
Der Cleint fragt SRRs nach einer Liste mit SREs und bekommt eine Liste
mit diesen.
Die prinziplielle Funktionalität ist die selbe. Aus der Erweiterbarkeit
(die im _weiten_ Sinne gegeben sein sollte, wenn man sich später nicht
über inkompatibilitäten ärgern will) folgt fast direkt, dass sich alles
in ein Kommunikations-Protokoll gießen lässt.
Zudem lassen sich Such-Anfragen bei meinem Konzept extrem einfach an
die nächst untere Ebene durch-reichen, falls dies nötig sein sollte.
> Eine Kernmaufgabe des Konzeptes ist ja, diese Prozesse durch
> Standadisierung zu "abstrahieren" wie zu "verteilen", da dies eine
> Vielzahl Vorteile (Offenheit, Effizienz usw.), dagegen nur
> marginale / lösbare Nachteile mitbringt.
Es bringt auch nichts als Overhead, vier mal das gleiche Protokoll zu
definieren. Abstraktion und Verteilung ist ja auch genau das, was ich
erziele. Erst die Abstraktion lässt alle enzelprotokolle ja
verschmelzen. Und Verteilen kann man besser, wenn zB ein SRE statt
zwei nur eine Such-Anfrage sowohl für "benachbarte" SREs als auch für
MIs formulieren muss und beide Antworten _formal_ gleich behandeln kann.


> 1.)
> Zur Dezentralisierung und Spezialisierung von Indizes wie des 
> Erfassungsprozesses insgesamt soll m.E. ein überarbeitetes /
> erweitertes SOIF als verbindlicher Standard zum Einsatz kommen.
Das wäre in meinem Fall die "Antwort".

> 2.)
> Typische Suchanfragen gegen die Indizes wiederum nutzen "andere"
> Protokolle gegenüber jeweils spezialisierten MIs, deren Protokolle
> vielfältig sein können / dürfen (allerdings muß sich auch darum
> jemand Gedanken machen, wenn er erste MIs implementieren will). Ein
> Basis Set der wichtigsten / "primären" MIs allerdings wird noch
> benötigt (z.B. MIs mit Zuordnung Keyword (Kombination) <-
> > Domain wie z.B. -''- -> URIs) bzw. kann von vereinheitlichten 
> Basiskonventionen stark profitiertieren (soweit habe ich noch nicht
> gedacht). Erlaubt wie denkbar wären auch mehrebige MIs (welche nach
> außen als ein MI erscheinen / nutzbar sind).
Das wäre die "Frage". Wahrscheinlich werde ich diesen So noch einen
groben Überblick über "Frage" verfassen. Dann sollte alles klarer
werden.


> Dennoch wird es auch vorkommen (wie Du auch bemerkst), das
> Suchanfragen z.T. auch einzelne Informationen direkt von den primären
> Brokern / Gatherern holen wollen (z.B. Angaben zur Aktualität von
> Metadaten, wenn diese entsprechend relevant ist oder noch nicht an
> einem MI zu haben sind) - dies kann m.E. wiederum im SOIF2 Kontext
> erfolgen - z.B. indem man die entsprechenden Felder anfragt und z.B.
> per UDP zusenden lässt (TCP ggf. Fallback).
Und hier genau das, wovon ich die ganze Zeit rede: Wenn ein Anwender
hinter einer NAT sitzt, muss er ständig UDP-Pakete an den
Server senden, um eine Antwort zu bekommen (Keepalive). Darum nicht
darin auch die Frage formulieren? Und warum sollte man nicht nach
beliebigen Feldern fragen, die dann -falls der SRE zB nicht weiß, was
damit zu tun ist bzw diese Felder nicht kennt- evtl von der nächst
tieferen Ebene behandelt werden?
Man kann Such-Anfragen formal auch so aufbauen, dass man mit einer
Syntax sowohl SREs nach -einem oder mehreren Rankings unterzogenen-
Suchergebnissen befragen kann, als auch SRRs nach URIs von SREs
befragen kann. Und das ganze ohne Overhead.

> Beste Grüße,
> Niels.
Grüße,
Julian