Früher oder später muss es ja doch sein, also jetzt oder nie.
Ich denke ernstlich daran einen neuen Client auf die Beine zu stellen.
Ich stelle mir das folgendermaßen vor:
Ein Teil des Clients wird Open-Source sein
d. h. GUI,
Datenstrukturen als relationale DB,
getrennte Module für:
Verwaltung der Library,
Abwicklung der Suchen,
Transfer & Queue Handling,
Verwaltung Verbindungen (Netzwerke / Chatserver)
Userlisten / Kommunikation / Chat
File-Handling / Hashing / File-Verification
Ein Teil der Module wird nicht Open-Source sein
d. h. Connect-Handling,
Block-Transfer & De- & Encoding,
Traffic-Management
Mit Ausnahme des letzten Punktes ist die letzte Gruppe im Grunde vorhanden und man muß sehen, ob KM bereit ist, seine Funktionen so aufzubereiten, dass sie per dokumentiertem Interface genutzt werden können, was ich optimistisch sehe.
Um zu modernen Standards aufzuschliessen, wird es nötig sein, eine Protokoll-Erweiterung zu entwickeln, dafür Handshake und Connection-Types so zu erweitern, dass der neue Client zum alten kompatibel bleibt und neue Funktionen, die ohne Protokollerweiterung nicht realisiert werden können, exklusiv zwischen neuen Clients abwickelt.
Ich möchte strikt nach Top-Down-Methode vorgehen,
zunächst einen Chart erstellen, sobald über die Aufteilung der Module Klarheit besteht, zu den Modulen Funktionslisten, Datensatz- und Formatbeschreibungen, Funktionen grob strukturieren und erst dann beginnen, einzelne Funktionen umzusetzen, wobei das GUI, die Datenbank (ermöglicht vor der Fertigstellung des Clients Dummy-Funktionen für Tests) und einen einfachen Responder, der als Netzwerk-Dummy fungiert, damit die einzelnen Module während der Entwicklung getestet wqerden können.
Ich hoffe, dass ich mich nicht völlig übernehme und das ich nicht der einzige bin, der daran ein starkes Interesse hat.
Als Entwicklungsumgebung schlage ich C++ vor, damit die Open-Source-Module für alle, die sich beteiligen möchten in einheitlichem Stil online gestellt und diskutiert werden können. Einzelne Funktionen in Assembler können evtl., soweit sie gut dokumentiert sind.
Was soll der Client können, das nicht im jetzigen Client enthalten ist:
Erweiterte Suchfunktionen, ID-Tags, Queue-Handling ala MxMonitor integriert, d. h. dynamische Upload-Slots, Suchergebnisse session-unabhängig, File-Verification, Identifikation bereits getätigter Downloads in Suchergebnissen, ID-Tag-unabhängiges Hashing für MP3, ID-Tag-Corretion (?), to be continued
Anregungen und Kritik erwünscht, Gruss, Sophosaurus
