Plugin-Architektur für Suche

Forum for developers

Plugin-Architektur für Suche

Beitragvon Nutomic » Do Jul 04, 2013 6:01 pm

Ich habe mir mal Gedanken gemacht, wie man Suchplugins sinnvoll integrieren könnte.

Die Plugins, die ich im Sinn habe, sind ausschließlich solche, die bei DuckDuckGo als "FatHead" bezeichnet werden (Beispiel). Unter anderem könnte auch die Autokorrektur so umgewandelt/ausgelagert werden.

Ich habe mir das folgendermaßen vorgestellt:

Bei jedem Suchaufruf wird in die erste Seite ein Script eingebettet, was eine Liste der Plugins auf dem Server übergeben bekommt.

Die Plugins werden alle aufgerufen (z.B. /plugin/*name*.html), und wenn die Antwort nicht leer ist, wird das unter der Suchleiste eingefügt.

Zusätzlich könnte vorher noch für jedes Plugin überprüft werden, ob die Query bestimmte Keywords enthält, und nur dann das Plugin geladen werden.

Der Ansatz hat den Vorteil, dass Plugins sowohl in Java als auch in Javascript (oder beides) sein können.
Nutomic
 
Beiträge: 8
Registriert: Do Jul 04, 2013 5:58 pm

Re: Plugin-Architektur für Suche

Beitragvon Nutomic » Mo Jul 08, 2013 4:33 pm

Kann einer von den Devs vielleicht was dazu sagen?

Ich will das nur ungern alles implementieren, um dann beim Merge Request zu hören, dass es eigentlich grundsätzlich keine gute Idee ist.
Nutomic
 
Beiträge: 8
Registriert: Do Jul 04, 2013 5:58 pm

Re: Plugin-Architektur für Suche

Beitragvon Orbiter » Mo Jul 08, 2013 10:52 pm

Hi Nutomic, entschuldige die späte Reaktion, das lag ganz und gar nicht an Desinteresse sondern im Gegenteil daran, dass ich mir für die Beantwortung Zeit nehmen wollte und genau die nicht richtig da war.

Die Idee ist ziemlich super! Ich hab vor zwei Wochen auch ein Tweet bekommen, der mich auf die Verwendung von 0-click Daten wie in Blekko hinweist:
Carlos Solís @csolisr hat geschrieben:@yacy_search I was thinking to get the data in real time, like you already do with Blekko. Get the 0-click site and parse it on the top.

Das wäre so ein Anwendungsfall. Ich hatte darauf geantwortet:
@csolisr zero-click is a good idea, but where did @duckduckgo get data? http://downloads.dbpedia.org/3.8/en/sho ... _en.nq.bz2 343MB download, so no centralization, good?

weil ich in YaCy ungerne so etwas wie Meta-Suche machen will, das würde verhindern dass wir mit YaCy als eigenständige Suchmaschine gesehen werden können.

genau in diese Richtung würde auch meine einzige Kritik gehen: eine schlechte Anwenung der FatHead wären solche, die Ergebnisse von anderen Servern einblenden würden. Das macht dann das Konzept der dezentralen und ansonsten selbstständigen Suchmaschine kaput.

Abgesehen von dieser 'Vorsichtsmaßnahme' ist dein Vorschlag der dazu notwendigen Architektur genau richtig. Eine Auslagern der Suchwortvorschläge in diese Technik macht ebenfalls Sinn. An dieser Stelle müssten wir uns fragen: wie sieht eine API für die Plugins aus? Hast du da schon eine konkrete Vorstellung?
Orbiter
 
Beiträge: 5792
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Plugin-Architektur für Suche

Beitragvon Nutomic » Di Jul 09, 2013 12:19 am

Woher die Daten kommen hab ich mir ehrlich gesagt fast gar keine Gedanken gemacht. Einiges könnte man lokal machen (zB Taschenrechner), ansonsten könte man auf freie Seiten wie Wikipedia zurückgreifen?

DIe Plugins habe ich mir so vorgestellt, dass das jeweils ein Ordner ist, mit einer .html-Datei und einer .java-Datei (bzw .class im Release), also genau wie die bestehenden Seiten, evtl zusätzlich .css, .js und weitere .java/.class.

Die Hauptklasse implementiert respond() und sowas wie doesLoad() (was anhand von Keywords prüft, ob das Plugin geladen werden soll). Wenn das Plugin geladen werden soll, wird das über Javascript gemacht (genau gleich wie alle anderen Seiten).
Nutomic
 
Beiträge: 8
Registriert: Do Jul 04, 2013 5:58 pm

Re: Plugin-Architektur für Suche

Beitragvon Orbiter » Do Jul 11, 2013 5:08 pm

ok das ist gut; das respond() bekommt als Parameter den Suchstring übergeben?

Wie hast du dir das vom Design her vogestellt, soll das Plugin ein fertiges html liefern? Wenn ja: mit einem festgelegtem css-vokabular? Wenn nein: dann braucht man ein Objekt, das gewisse Metadaten beinhaltet, wie Headline, Comment line, Link etc.

Auch wenn es unsauber ist wäre ich eher für das html, weil man dann völlig frei ist in der Gestaltung; man könnte auch Bilder oder Karten im Plugin anzeigen; oder Graphen oder eben vieles; sogar neue Navigtionsmittel.
Orbiter
 
Beiträge: 5792
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Plugin-Architektur für Suche

Beitragvon Nutomic » Do Jul 11, 2013 5:39 pm

Richtig respond() bekommt die Query (vllt. besser direkt als Array?!)

Das HTML soll ja einerseits einheitlich aussehen (Hintergrund, Rand, Titel), aber andererseits beliebigen Hintergrund darstellen. Ich denke am besten wäre eine div (die für jedes Plugin identisch ist und evtl. auch Titel etc. übergeben bekommt) und mit CSS den gleichen Style bekommt, und in die div kommt dann das HTML vom Plugin.

Also äußerer Container (div), der für jedes Plugin gleich ist, mit Titel etc. als Parameter, und beliebiges HTML vom Plugin darin.
Nutomic
 
Beiträge: 8
Registriert: Do Jul 04, 2013 5:58 pm

Re: Plugin-Architektur für Suche

Beitragvon Lotus » Fr Jul 12, 2013 9:19 am

Man könnte doch wahrscheinlich auch die Plugins wie die Templates in htroot/env/templates einbinden. Dieses Template bindet dann die Plugins ein (also eine Verkettung Suchseite-Template-Plugin). Dann wäre das Interface so wie bisher, und es gibt alle Daten, die verfügbar sind.
Lotus
 
Beiträge: 1699
Registriert: Mi Jun 27, 2007 3:33 pm
Wohnort: Hamburg

Re: Plugin-Architektur für Suche

Beitragvon Nutomic » Fr Jul 12, 2013 1:18 pm

Ich hab mir noch nicht genau angeschaut, wie die HTML-Generierung jetzt gemacht wird, aber wenn sich das mit bestehender Funktionalität machen lässt, ist das natürlich umso besser.
Nutomic
 
Beiträge: 8
Registriert: Do Jul 04, 2013 5:58 pm


Zurück zu YaCy Coding & Architecture

Wer ist online?

Mitglieder in diesem Forum: YaCy [Bot] und 1 Gast