Hallo inherited,
ein Lob für Deinen Ansatz, wobei ich gerade bei der vorhandenen Auswahl (
Indy, ICS und Co) denke, es wäre zu viel Arbeit auf Dauer für Dich alleine. Es gibt bei Torry etliche Komponenten/Units, die ähnliches versuchen.
Zitat von
Relicted:
(ich persönlich halte nicht so das meiste von den indys...)
Das verstehe ich nicht. Jetzt muß ich nachdem ich immer wieder
Indy-bashing sehe, was erklären:
Das größte Problem liegt an der "Klassen-Orgie" innerhalb der Indys. Viele haben einfach damit ein Problem, sich da einmal einzulesen. Aber ich habe mich auch in die Indys einarbeiten können...
Zitat von
Sherlock:
und ich hoffe du verzichtest auf diese seltsame Antifreeze Geschichte.
Ja, diese Komponente gibt es auch nur für "Programmierer", die mit Threads nicht umgehen können. Wie oft wird hier die Frage gestellt, warum bei (blocking Sockets &)
Indy die Anwendung freezt. Dann wird schnell mal Application.ProcessMessages in den Raum geworfen und alles ist gut... So geht es natürlich nicht.
Aber die Komponente jetzt in TIdTryToAntiFreezeMyAppForDummies umzubenennen wäre auch keine Lösung.
Zitat von
sirius:
Ui, sich mit
Indy zu messen, dürfte nicht so einfach sein. Außerdem bekommst du dann auch wieder so eine riesen große Bibliothek, was du, so vermute ich, gerade eben vermeiden wolltest.
Eben.
Denke an den Funktionsumfang von ICS (100 .pas Units) oder
Indy (jetzt 352 .pas Units in Core/System/Protocols). Da sind ja nicht nur Units für Delphi/FPC, Sockets für Windows und Linux, sondern auch IPv4/IPv6 Unterstützung, Hash und Enconding/Decoding, Typumwandlungen und Prüfungen,
RFC Standard-Umsetzungen, Server/Client-Abstraktionen,
FTP List-Parser für die verschienen Gegenstellen (bei
Indy allein ~ 40 Dateien), SSL Protokolle,
SSH für kommerzielle Komponenten etc.pp.
Du brauchst auch -sehr- viel Hintergrundwissen in Bezug auf die Eigenheiten der unterschiedlichen Implementationen von "Standards", zu denen Du eine Verbindung herstellst.
Zusätzlich kommt der administrative Aufwand und die Kompatibilität zu älteren (und neueren) Delphi Versionen und Windows Versionen hinzu.
Arno Garrels, der am ICS mit(ge)arbeitet (hat?) schrieb einmal, daß einige ICS Klassen, wie z.B. TSmtpClient/TFtpClient endlose if-then-else Spagetti-Code enthalten. Bei den Indys sind es halt die vielen verkapselten Klassen...
Grob gesagt: ICS = protokollnah,
Indy = Verkapselte Klassen für hohe Abstraktion.
Das manche Programmierer, gerade Einsteiger, bei mangelndem Leitfaden hier überfordert sind, trifft sicherlich zu. Aber das macht den Code nicht schlecht, defekt oder was sonst auch immer in den einzelnen Threads vorgeworfen wird.
Genau so wie es Threads gibt mit "wie Programmiere ich einen Treiber in Delphi" oder "wie Programmiere ich ein Betriebssystem in Delphi" - am besten innerhalb von einem Tag - gibt es bei den Indys auch fehlende Grundkentnisse beim Programmierer, die zu Problemen führen.
Ich habe mich seit ich hier bin für die Indys erwärmen können. ICS ist sicherlich nicht schlecht, eben anders und für andere Problemstellungen. Der Vorteil für mich war, daß die Indys gleich bei Delphi dabei waren und so einem Ausprobieren nichts im Wege stand.
Gruß Assertor
Just my 2 Euros (too long for 2 ct)