TEAM maui: Indexing_server Erstellt am 18/05/05 um 01:26:12 CET von Stargater

Hallo Community,

Einie Mitglieder des TEAM maui haben sich schon länger sich mit den Thema "Inovative Software" für BeOS/ZETA beschäftigt.
Nun hier und heute kann man eine erste Veröffenlichung bestaunen.

http://tm.kaldience.com/dir/members/GenkiColo/Indexing_server.pdf

Eine Projektbeschreibung in PDF vormart mit Mockups (ZETA Preferenzes erweiterung)

Ich bitte um Diskusion und an alle Entwickler um Mithilfe bei der Umsetzung dieser Projektbeschreibung.

MFG Stargaterwww


Kommentare:


Textsuche

Geschrieben am 18/05/05 um 08:08:54 CET von Wiese66

Hi,

mit der Idee schlage ich mich auch schon länger rum. Prinzipiell habt ihr einen guten Ansatz. Ich würde aber versuchen die Vorgaben der zu indezierenden Daten nicht statisch zu machen. Sondern von Grund auf, auf modularer Ebene, sprich mittels Add-Ons. Dieses sollte sich dann in einer flexiblen GUI niederschlagen.
Auf diese Weise können Add-Ons für Bilder, Texte, Multi-Media geschrieben werden, die auf die Translators zurückgreifen. So würde durch einen neuen Translator auch automatisch der neue Dateityp mit geindext werden. Für andere Dateitypen (z.B. PDF) würde man dann ein neues Add-On schreiben.
Und gerade bei dem letzen Punkt, dem Indezieren von Text-Files ergibt sich ein größeres Problem. In wie weit will man Datei-Inhalte(!) mit in die Suche aufnehmen. Hier Punktet Spotlight eindeutig. Da AFAIK BeOS aber Attribute in Stringform nur bis zu einer Länge von 255 Zeichen in die Suche mit einbezieht, würde sich hier leider ein Problem ergeben. Da habe ich leider noch keine gute Lösung für gefunden.

Grüße,
Chris
 
WOW

Geschrieben am 18/05/05 um 08:12:41 CET von Andre Stark

Das schaut fantastisch aus! Von der Beschreibung und den Screenshots her perfekt durchdacht. Leider bin ich immer noch nicht fähig anständig C++ zu basteln und COBOL-Entwickler werdet ihr dafür nicht brauchen.
Wenn was getestet werden muss bin ich aber sofort dabei: @ anDOTstarkATwebDOTde
 

Super

Geschrieben am 18/05/05 um 11:00:10 CET von ZzLeCzZ

dachte schon ich muss zu skyOS wechseln
ich denke auch die AddOn loesung sollte gewaehlt werden.
Textsuch find ich auch ein Problem. Weiss jemand wie spotlight das genau macht? Das Textfile wuerde ja ca. doppelte groesse annehmen wenn man den inhalt nochmal in attributen speichern wuerde. Ich denke man muesste die textfiles schon indiziert auf der festplatte speichern (wie in einer datenbank).. aber das geht ja nicht mit dem bfs...
 

Idee

Geschrieben am 18/05/05 um 12:45:04 CET von Stargater

Also mit denn Atributen und Inhalte in Text files (txt,doc,etc.), wird es mit nur einen Add-on nicht getan sein.

Eine Idee wäre, eine erweiterte suche:
==> beim Indexing Pref: metadaten gegen endung (mimeTyp) austauschen und dann im
entsprechenden file Suchen.
Treffer mit der höchten quote Tabelarisch aunzeigen.

Mime Typ wären alle Text dateinen, wie:
txt,tex,html, (scripte), doc, etc.

Es wäre eine art switch on thy fly, normalerweise sucht mann Atribute , bei denn text inhalte würde das nichts bringen, da keine metadaten vorhanden sind die man in Atributen wandeln kann. Also müste ein switch her, der bei denn etsprechenden Text files (Localisiert durch die mime Typs), die texte nach denn zusuchenden wort sucht und katalogisiert in form von Atributen wie z.b =, nach häufigkeit , genauigkeit, Aktuallität (datum),etc., auch fehlerhafte datein werden Katalogisiert, da ja auch mal ein mimetyp falsch sein kann.

MFG Stargater
 

 @Stargater

Geschrieben am 18/05/05 um 13:16:47 CET von Wiese66

Um Attribute zu erzeugen muss eine Datei ja nicht zwingend Metadaten direkt selber zur Verfügung stellen. Die Größe, Farbtiefe und möglicher Alphakanal etc. eines Bildes muss man auch unter Umständen erst auf bestimmte Arten extrahieren.
Bei Textdateien (o.a. PDF. DOC...) könnte man Wörter die fast in jedem Text vorkommen ignorieren (ich, er, he, she, can...) und so den Umfang dramatisch redudzieren. Da bleibt dann aber trotzdem das Problem der Stringlänge (und deren Reduzierung).
Desweiteren sollte vllt. auch in Erwägung gezogen werden, nicht ein neues Programm zu schreiben, sondern den Haiku-Registrar um diese Arbeiten zu erweitern?!?

Grüße,
Chris
 

 vor allem...

Geschrieben am 18/05/05 um 17:38:19 CET von css

sollte man nicht alles an information grabben, sondern nur das, was sinnvoll ist, also z.B. interpret - album - titel stil bei audio, Bildgröße - Datum - Farbtiefe bei Bildern.
Aber wer braucht shon wortzahl oder absätze bei text? hier ist es doch sicherlich sinnvoller, Titel und Überschriften (sofern entsprechend formatierter Text vorliegt natürlich) stichpunktartig aufzulisten, eventuell noch erstellungsdatum, vielleicht noch den autor(bei einem singleuser Desktopsystem?) der Rest ist eher unnötig.
Schliesslich soll das Ganze ja das finden unterstützen, nicht einen weiteren suchhaufen aufschütten, oder?
 


Textanmerkung

Geschrieben am 18/05/05 um 20:48:21 CET von Paradoxon


Ich denke bei Text ist da noch sehr viel möglich, z.B.: gibt es unter Windows sehr teure Programme die schon "rudimentär" den Inhalt erfassen können und dann in der Lage sind alle Dokumente zu einem bestimmten Themenbereichen "herauszusuchen".

Ich bin der Meinung das dürfte mit einem normalen Addon, dessen Schnittstellen gut definiert wurde, möglich sein.
Fehlen nur noch die Algorithmen
 

Frage:

Geschrieben am 18/05/05 um 21:31:15 CET von Stoertebeker

Soll der Indexing Server (siehe auch Indexdienst unter Windoze) auch fehlende Attribute in Dateien aktualisieren/korrigieren/setzen?

Das waere natürlich wichtig und sollte mit eingebaut werden, falls nicht schon angedacht.

Ich würde bei dem Ansatz sogar noch etwas weitergehen und das 'reindexing' Tool von Axel mit einbinden in der App (wenn nicht schon in Benutzung).

Ich würde _dann_ noch sogar einen drauflegen (wenn möglich):
Den Index vom Indexing Server regelmaessig _defragmentieren_ lassen. Das könnte man evtl. folgendermassen machen, indem zunaechst ein image des Index erstellt wird oder eine 'Schattenkopie'. Anschliessend müsste der Index in einem Set zurück überschrieben werden.

Bei dem kontinuierlichen Indexing - Dienst sollte man die idle-Intervalle der CPU checken und in diesen den Indexing Server seine Arbeit tun lassen.

Bei dem, 'was' im Indexing drin sein sollte oder nicht, darf man BeOS Standards nicht ausser Acht lassen und sinnvoll erweitern. Da kann man sonst mehr kaputt machen im FS als man denkt.

Die für andere Plattformen so wichtigen Endungen sollten auch Win-konform gehalten werden.
Ist halt so, das man 'compatible' bleiben muss zur '95% - Welt' (siehe Beispiel .gobe -> ist z.B. korrekter .gpd).

Ansonsten waer hier ein etwas 'professionelleres' Feedback für den Indexing Server in der GE - Mailinglist zu bekommen, wenn nicht schon geschehen

Ich würde auch den 'Umfang' eines Indexing Tasks für eine Filetype in 'Priority levels' in eine queue stellen.

Ausserdem könnte der Indexing Server user-spezifische Tracker-Suchen ebenfalls analysieren (s. Tracker Query history) und einen Ergebnis - Cache einrichten und regelmaessig aktualisieren...

So könnten die Query Ergebnisse sofort angezeigt werden, die live-query des trackers würden dann das Ergebnis nach und nach korrigieren (Query Ergebnisse löschen/modifizieren/ergaenzen)...
 

formate

Geschrieben am 19/05/05 um 13:21:14 CET von dr_evil


audio-formate:
mod, xm, it, s3m wären noch toll

video-dateien:
ogg
 

super

Geschrieben am 20/05/05 um 19:21:10 CET von piccollo99


Mit Lotus Notes kann ein Index nicht nur über die eigentliche Notes-Datenbank (Text) erstellt werden, sondern auch alle darin enthaltenen Attachments (z.B .doc, .xls, .ppt usw.) Der Index wird zwar groß (ca. 50 % der Datenbank), aber ein Argument in einem Attachment wird gefunden.
Wie die Notes-Leute (jetzt IBM) das hinkriegen; keine Ahnung, aber es funktioniert.
Der Ansatz ist jedenfalls super, denn je größer die Festplatten werden und je mehr Dateien darauf "rumfliegen", desto schwieriger wird es und länger dauert es, bis man was findet.
Bald gibt's 500 GB Plattern. Die Terabytegrenze wird in ca. 3-4 Jahren fallen
Super, dann brauch ich nix mehr zu löschen. Und M$ wird in der nächsten WiX-Version den Papierkorb vom Desktop nehmen ) *lol*