Projektgeschichte
Von Suchinfrastruktur
zu einem breiteren Engineering-Labor.
Egothor begann 1998 als Suchmaschinenprojekt. Im Lauf der Zeit untersuchte dieselbe Engineering-Linie Sprachverarbeitung, verteilte Dienste, Crawling, Netzwerk-Geolokalisierung, Sensor-Gateways und experimentelle Datenplattformen. Diese Seite bewahrt diese Entwicklung, ohne eingestellte Systeme als aktuelle Produkte darzustellen.
Zentrale Entwicklungslinie
Egothor Search Engine
Eine Open-Source-Volltextsuchmaschine in Java mit dynamischen Index-Updates, Transaktionen, Plagiatserkennung, inkrementellen Updates, gängigen Dokumentformaten, erweitertem booleschem Modell und sprachunabhängigem Stemming.
Historische Zusammenfassung ↑J5M
Eine schlanke Schicht für verteilte Anwendungen mit kooperierenden Diensten, Discovery entfernter Objekte, direktem oder Remote-Aufruf, Lifecycle-Steuerung und Hot-Spare-Serviceinstanzen.
Historische Zusammenfassung ↑Bobo
Eine verteilte Crawler- und Virtual-Entity-Plattform, die aus den Crawling-Anforderungen von Egothor zu einer allgemeineren Architektur für autonome webnahe Komponenten entstand.
Galeo
Forschung zur IP-Geolokalisierung mit einem Modell, das Netzwerkpfade als heterogen behandelte, statt eine konstante Ausbreitungscharakteristik anzunehmen.
Egothor3 / Q!D
Eine 2012 begonnene experimentelle Datenbankrichtung; die spätere Q!D-Implementierung nutzte J5M, um alternative Verarbeitungsmodelle für große Datenbestände zu untersuchen.
Aktuelle Egothor-Generation
Radixor erneuert die Sprachverarbeitungslinie, ZeroEcho erweitert die Arbeit um moderne Kryptographie, conflux liefert fokussierte Anwendungsinfrastruktur, MethodAtlas wendet evidenzorientiertes Engineering auf Software Assurance an und EGOTHOR v4 führt die Projektfamilie zurück zur Volltextsuche für regulierte Umgebungen.
Aktuelle Projekte →Angewandte Systeme
Zur breiteren Projektfamilie gehörten auch Systeme rund um Netzwerke, Sensoren und Datenerfassung. In Leo Galambošs historischer Projektliste finden sich unter anderem SNOG (Sensor-Network-Gateway), SafetyCare (GPS/GSM-Unterstützungsanwendung), Cyclone (verteilter Feed-Crawler und Analyzer) und RaSPEL (LoRaWAN-zu-REST-Bridge/Controller).
Was weitergetragen wurde
Die einzelnen Systeme unterscheiden sich, doch mehrere Ideen kehren wieder: Komplexität aus kritischen Runtime-Pfaden verlagern; Serviceverhalten explizit machen; kompakte Datenstrukturen bevorzugen; Komponenten unabhängig ersetzen oder weiterentwickeln können; und ausreichend technische Evidenz zu einer Aussage erhalten, damit ein anderer Ingenieur sie überprüfen kann.