[Seeky] Draft

[Julian Ganz]

On Mon, 7 Mar 2011 12:01:21 +0100
Niels Dettenbach <nd at syndicat.com> wrote:

> Hallo Julian,
> 
> 
> an dieser Stelle meine Bemerkungen zur zweiten Hälfte Deiner Mail.
> Nochmals vielen Dank für Deine Ideen und Gedanken.
> 
> Einzelne Dinge dürften so bereits im aktuellen Konzept:
> http://seeky.org wiederzufinden sein - ggf. mal wieder reinschauen
> (s.a. "Historie" am Ende der Startseite sowie die zitierten Links /
> neuen Subseiten).
> 
> Am Donnerstag 03 März 2011, 01:18:50 schrieb Julian Ganz:
> > 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.
> Wenn Du PLBs / Harvester / Gatherer meinst - ja (siehe Link / neue
> Seite).
> 
> Als Datenformat kommt (im Konzept) ein modernisiertes /
> überarbeitetes SOIF(2) zum Einsatz, das ich nochmal genauer
> aufschreibe und gern diskutiert werden kann (s.u.).
Grob, was ich mir vorgestellt hatte.

> Die beteiligten, grundlegenden Formate sollen explizit einfach, offen
> und nicht implementierungsgebunden sein.
Erklärt sich von selbst.

> Im Prinzip ordnet SOIF einer netloc bzw. URL einen Datensatz in Form
> eines Hashes mit numerischen Feld-IDs zu, wobei die Feld IDs z.T.
> standardisiert sind, der Standard erweiterbar ist (ähnlich TCP/IP
> Ports) oder ggf. auch private / unstandardisierte Felder haben kann.
> Im klassischen SOIF sieht man die IANA als Instanz vor um neue Feld
> IDs mit neuen Datenfeldern standardisiert zu belegen. Ob und wie weit
> das pratikabel ist, müsste man mal betrachten.
Wie in einer vorherigen Mail angedeutet könnte man sich überlegen,
welche Vor- und Nachteile Strings hätten.

> Im vorgesehenen SOIF(2) sollen Die Feldinhalte mit Strings wie
> mehrdimensionalen Arrays belegt werden können (je nach
> Feld-Definition), die u.U. auch binär sein könnt(e)n (Standard?).
Klärt sich mE. von selbst. Mit der definition eines neuen Feldtypes
muss auch klar definiert werden, was wie darin untergebracht wird.

> Meine ersten Ideen Arrays ins Strings zu packen liefen in Richtung
> JSON u.ä., da bandbreiteneffizient wie einfach und transparent.
Die Nutzung einer offenen und schon implementierten
Serialisierungsmethode wie JSON oder BSON (zumindest für _Inhalte_ von
Feldern) hätte mE nur Vorteile. Man muss das Rad nicht neu erfinden und
man macht die Implementierung komplexerer Daten-Übertragung einfacher.
> Wie weit Zeichensätze verwendet werden dürfen - z.B. nut UTF-8 oder
> beliebige - wäre auch noch zu debattieren.
Meiner Meinung ist UTF-8 die logische Entscheidung für Zeichenketten. Es
gibt keine Probleme mit Endianess und alle Zeichen, die von irgend wem
benutzt werden wollten werden entweder jetzt oder in absehbarer Zeit
unterstützt.

> Damit wäre ein recht flexibles, recht effizientes wie recht einfaches
> wie frei erweiterbares Datenformat als Konvention da, auf dessen
> Basis Harvester / Gatherer oder auch PLBs mit MIs Daten austauschen
> können. Zudem können (ähnlich Web) Komprimierungen oder auch
> Kryptotechniken verwendet werden.
Meine Rede.

> > 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.
> 
> XML sehe ich im bisherigen Konzept als eine Option der Protokolle:
>  - zwischen MIs und SRRs
>  - zwischen MIs und MIs
>  - "Steuerdaten" zwischen MIs und PLBs
> 
> aus diversen Gründen (z.B. Performanz, Datenvolumina, Aufwand zur
> Generierung) halte ich für die Übertragung der "summarierten" Daten
> ("Archivdaten") zwischen PLBs und MIs ein überarbeitetes SOIF (siehe
> RFC-Links im Konzept) - z.B. "SOIF-NG" oder "SOIF2" für praktikabler
> wie effizienter.
Gerade hier vergisst du -glaube ich- jede Menge Nutzer, die nicht
selbst hosten, sondern nur über HTTP-Anfragen auf ihre Websites
kommunizieren können. XML wäre hier ideal für integrierte
Such-Interfaces (zB in Form von PHP- oder CGI-Scripten).
Zudem: vergleicht man betreffende Seiten-Downloads mit einem
Komprimierten XML-Index-File (Formatsfragen mal außen vor gelassen)
gewinnt/spart man immer noch Traffic.

> > 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.
> Ja,
> deshalb ist UDP auf ggf. allen Ebenen optional vorgegeben und sollte
> in einigen Interaktionsformen zwischen MIs und PLBs unbedingt
> präferiert werden (TCP max. als "Fallback").
Dass UDP in solchen Fällen -falls denn möglich- Sinnvoll ist, erklärt
sich von selbst.

> > 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.
> Ja,
> allerdings bitte hier klar zwischen der Kommunikation von PLBs / MIs
> (SOIF-NG bzw. "SOIF2").
...unterschieden werden? (Der Satz war nicht vollständig)
Klar sollte sich hier auch klären, ob gefragt oder geantwortet wird und
im letzteren Fall auch auf was.
An sonsten sollte man sich den Header hier als eine Art zusätzliche
"Netzwerk-Schicht" vorstellen, die dazu da ist, Funktionalität, die
man bei einem direkten Stream hätte, nachzubilden (worauf antworte
ich?), sowie Verschlüsselungs- und Komprimierungs-Fragen zu klären.

> Die beteiligten UDP-Implementierungen habe ich noch nicht im Kopf,
> hier besteht also auf jeden Fall noch Gestaltungsbedarf.
Dazu die Diskussion.

> > 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.
> Kryptographie wie Kompression sollte optional auf allen Ebenen
> möglich sein, aber nicht zwingend. User wie Webmaster sollen bei
> Bedarf selbst entscheiden können, welche kryptografischen
> Technologien / Strukturen sie präferieren und sich entsprechenden MI
> "Anbietern anschließen" bzw. ungewollte "ausschließen".
Vollkommen. Nur muss geklärt sein, _wie_ das passiert.

> Kryptographie ist nicht zwingend in allen Anwendungen erforderlich
> und damit womöglich für manche schlicht Overhead (und wir wollen doch
> auch die Umwelt wie Geldbeutel schützen... ;).
Zwei Bytes für zwei Leere Strings, die sagen, dass man weder
Verschlüsselung noch Komprimierung benutzt, machen heut zu Tage nichts
aus. Bei der Rechenzeit sieht es ähnlich aus.

> > 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.
> 
> -> ein "Suchdienst" im Kontext des SEEKY-Konzeptes wäre der Bereich:
> SFE/SRR/MIs bzw. SLBs
Und wie wird der angesprrochen? Warum nicht ein Protokoll aufsetzen,
dass gleich auch diese Anfragen direkt erlaubt?

> [Beispiel]
>
> Meine Empfehlung ist daher bisher, das MIs den "Suchenden" eigene,
> mehr oder weniger "wohldefinierte" Schnittstellen bereitstellen und
> ggf. geeignete Bibliotheken für z.B. Perl / Python herausgeben.
Wenn wir ein Protokoll für alles, was Suchen angeht, aufbauen, brauch
man hier keine zusätzlichen Gedanken betr dieser Schnittstellen zu
verschwenden.

> > 3.1) Direkte Verknüpfungen:
> > Hier sollte man die Binäre/UDP-Variante benutzen.
> Meinst Du damit "Direktzugriffe" von SRRs oder gar SFEs (also den
> "Suchclients" selbst) auf die PLBs? Ja.
> 
> > 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.
> Dies ist gem. Konzept Teil von Harvest/Gatherer, die die
> "datensammlung" und Speicherung übernehmen.
> 
> Die Seite dazu fehlt bisher noch (kommt noch nach) - einige
> Grundprinzipien der flexibleren Datenerfassung sind aber
> bereits/inzwischen hier beschrieben:
> http://seeky.org/primary_level_broker.html
> 
> Neben dem klassischen "Crawlen" gibt es weitere Methoden, den
> "SOIF-NG" datenbestand des jeweiligen PLBs zu "füttern" - z.B:
> 
>  - on request basiert (d.h. Seiten / Dokumente werden bei Abuf /
> Auslieferung durch den (Web-)Server "erfasst")
Diese Arbeit wäre eigentlich auch Ideal für (zB als Browser-Plugin)
Integrierte Such-Widgets (SREs) geeignet. Man stelle sich einen Browser
vor, der von einer Liste an Antworten (uU schon gerankt und vom
Browser-Plugin vorsortiert) abarbeitet, in dem er Seiten im Hintergrund
lädt und nochmals anhand lokal verfügbarer Mittel und Algorythmen einem
Ranking unterzieht und evtl als Irrelevant erklärt.

>  - Crawler Module erlauben das gezielte "crawlende" Erfassen von
> dynamischen Seiten per Modulauswahl und-Konfiguration - einfaches
> Beispiel für ein Modul wäre z.B. für den sitemap.xml Standard.
Wie schon angesprochen im Hinblick auf XML und robots.txt: lässt sich
alles recht gut und ohne Probleme implementieren. Man muss nur das ein-
oder andere beachten.

>  - spezialisierte Applikationen / Scripte, die auf den SOIF-NG
> Datenbestand schreibend zugreifen können. Somit kann sich jeder nach
> Bedarf selbst ein Konzept zur "Seitenerfassung" bauen, falls seine
> Anwendung nicht schon mit z.B. obigen Varianten korrekt wie umfassend
> erfassbar ist.
In wie fern unterscheidet sich das von Crawlern?

> > 3.3) Statisch
> > Eine URI zu einem einfachen Dump-File.
> Ja,
> PLBs bieten MIs Datenbestände wie -differenzen als (optional
> komprimierte) Dumps an. Der Mechanismus wäre noch zu definieren -
> z.B. anhand Beispielen aus der Versionsverwaltung
>
> URI ist richtig (war für mich logisch - hab's bisher dennoch nicht
> aufgeschrieben)
In diesem Fall ist ein PLB aber der Web-Host selbst, nicht der Crawler,
der auf einem externen Server oder bei jemandem zu Hause läuft. So
unterscheidet sich auch der Mechanismus. Ein PLB-Client in Form eines
Deamons auf einer Workstation, der nebenbei läuft, kann dann den Dump
einfach vom Web- oder FTP-Server ziehen und in einem größeren Haufen
mit an einen MI schicken oder evtl den MI direkt im nächsten Haufen
benachrichtigen, damit dieser den Dump selbst herunterlädt.

> PLBs halten gem. Definition SOIF-Daten für eine oder multiple Domains
> bzw. URI-Spaces vor - autoritiv oder nicht autoritiv (hier noch unter
> http://seeky.org/meta_indizes.html "Auffinden / Lokalisieren von PLBs"
> beschrieben) - wobei es zur Lokalisierung PULL wie PUSH Methoden geben
> kann/sollte.
Zu "non authoritive" PLBs: Die Qualitätssicherung könnte man hier
relativ einfach durch statistische Methoden und "Nachfragen" bei
anderen Crawlern implementieren.


> > 4) Netzwerk:
> > Hier gibt es mehrere Möglichkeiten:
> Ja,
> zeichne ich die Tage mal auf, weil die beschreibung ggf. wenig
> nachvollziehbar ist.


> > 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.
> Ja,
> wobei die Anfrage in SEEKY Topologie vom SFE ("Such Frontend")
> initial immer an einen SRR (Search Request Router) geht bzw. gehen
> sollte (SRR kann je nach Anwendung auch als Teil des SFE realisiert
> sein).
Wäre in vielen Fällen sinnvoll. Siehe weiter unten.

> > 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.
> Bitte hier nicht MIs mit PLBs verwechseln.
Ich verwechsle nicht. Ich sehe nur nicht ein, warum ein Client nicht
beides machen dürfen sollte. (gecrawlte Daten können ja trotzdem zu
anderen MIs übermittelt werden). Siehe weiter unten.
> MIs können alles, müssen aber gar nichts abbilden. Sprachdefinition
> wäre Teil des SOIF (PLBs <-> MIs) Satzes bzw. ein reserviertes "Feld"
> in SOIF Datensätzen.
Yep. So auch gedacht.

> In der Regel kommunizieren MIs nicht oder nur in einzelnen
> Anwendungsszenarien untereinander oder mit SLBs (Meta-PLBs die u.a.
> zu Caching Zwecken agieren können.) Denkbar wäre, in der
> Kommunikation von MIs mit PLBs oder SLBs mit "Entfernungen" zu
> arbeiten und so einen MI entscheiden lassen, ob er z.B.
> SOIF-datensatz zu http://xyz.com/abc.de von einem PLB oder einem
> "näheren", damit als Cache fungierenden "SLB" holt.
uA so gedacht.
> Entscheiden sollte im Zweifel der Anwender, der ev. lieber Aktualität
> haben will dafür mehr Zeit in Kauf nimmt usw.
Hier stimme ich vollkommen zu. Nur sollte prinzipiell die Möglichkeit
bestehen.

> > (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).
> P2P halte ich nur für einen Teil der Infrastruktur (z.B. MIs <-> MIs)
> für sinnvoll - so könnten sich einzelne MIs z.B. auf ein weithin P2P
> basiertes "Suchnetz" auf SEEKY Basis "spezialisieren" und so z.B.
> auch soziale Komponenten einbeziehen (Rankings usw.).
Ich glaube, du unterschätzt, wie eine Suchanfrage in einem P2P-Netz
Skaliert. Klar ist dies erstmal interessant, wenn es darum geht,
schnell eingestampfte (nach dir: destillirte) URIs zu Suchbegriffen zu
erhalten, die dannach gerankt werden sollen, aber wenn man dazu gleich
von anderen Nutzern wertvolle Informationen für den weiteren
Such-Verlauf auf dem eigenen Rechner bekommen kann: wieso nicht?
Und wieso sollen diejenigen, die eine Such-Anfrage weiter leiten, nicht
davon profitieren sollen, wenn sie evtl 10min später nach einem
ähnlichen Suchbegriff suchen?

> Bitte bedenken, das die MIs zumindest gem. Konzept "spezialisiert"
> sind und keine einheitlichen Infrastruktur entsprechen (müssen).
Ich glaube, du verstehst hier falsch. die Spezialisierung bleibt
erhalten:
1) Anwender startet App/Client und es werden über den SRR MIs (evtl auch
P2P-Kontakte, wobei hier der lokale MI bzw PLB angeboten wird) gesucht.
2) Anwender tippt Suchanfrage ein. Suchanfrage wird in Standart
übersetzt und wandert zu MIs auf:
2.1) festen Servern
2.2) dem eigenen MI (gefüttert durch den eigenen PLB)
2.3) den P2P-MIs
3) MI-Antworten gehen an das lokale SFE und werden dort (unter
Berücksichtigung der in den Antworten enthaltenen Informationen,
welche auch Rankings anderer enthalten könnten) gewichtet.
4) Die Such-Ergebnisse werden präsentiert.
All dies kann man über ein Socket abwickeln, wenn ein Protokoll für
alles verwendet wird.
> Denkbar aber wäre schon, P2P Strategien auf einem Teil der MIs zu
> realisieren wie anzubieten.
>
> So könnten Nutzer z.B. problemlos P2P basierte wie alternative MIs in
> ihre Suchkonzepte / - aufträge einbeziehen und die Ergebnisse
> kombiniert nutzen (SRR).
Das war die Idee.


> > 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.
> Ja,
> das ist alles denkbar und wären im SEEKY Kontext keine "Plugins"
> sondern eigenständige "SFEs"
Klar, nur aus der Sicht des _IM-Clients_ sind dies Plugins. Daher die
Formulierung.
> (Such Frontends, die - um Mißverständnissen vorzubeugen, auch eine
> Anwendung oder Agenten usw. sein können). Denkbar wäre auch, das
> spzialisierte MIs derartige Zusatzanwendungen anbieten (dann eher
> doch "Plugin"), da sie eh "näher" an den jeweiligen Metadaten sind.
> MI-Betreiber müssen ja auch Geld verdienen können, wenn auch in einem
> freien Wettbewerb.
Yep

> Auffinden / Lokalisieren von PLBs.
> 
> autoritive
> - DNS SRV und/oderTXT records, die auf autoritive PLBs zur Domain
> zeigen (PULL)
> - HTTP Protokollfeature (announcement SOIF Features / Protokolle per
> GET) (PULL)
> - robots.txt (neuer Tag z.B.: PrimaryLevelBroker, SecondLevelBroker,
> Allow/Deny)
> - HTML meta tag
> 
> low or non autorivite
> - ggf. eine öffentliche Liste verfügbarer PLBs / MIs (PUSH)
> - ggf. (ggf. zweiter Schritt) P2P basiert (m.E. höheres
> Mißbrauchspotential bzw. mehr Aufwand)
Siehe meine Antwort weiter oben (Statistik etc.)

> Beschreibung Inhalte:
> - sitemap.xml
> - HTML Meta Tags (robots.txt)
> - robots.txt
Hier fehlt mE noch ein <rel>-Tag und evtl andere Maßnahmen für andere
Protokolle.


> ---
> Noch kurz was Organisatorisches:
> 
>  - werde die seeky.org Seite als Wiki umorganisieren und die Inhalte
> besser / neu gliedern - gerade offene Punkte können dann am Wiki
> debattiert und vorgeschlagen werden
> 
>  - bei weiterem Interesse würde ich Dich mit in die Liste der
> Konzeptentwickler auf der Seite führen.
> 
> Zeit ist wohl bei uns allen ein rares Gut - bitte entschuldigen wenn
> manche Dinge noch unvollständig dargelegt sind und sicher noch Typos
> vorkommen usw. Ich gelobe Besserung ;)
> 
> 
> Beste Grüße,
> Niels.
Grüße,
Julian

PS: Wer ist außer Niels und mir denn überhaupt alles noch hier?