Generelle Frage zu den Indy-Komponenten

[greenmile]

Finally ist ne tolle Erfindung

[Der schöne Günther]

Thema nur quergelesen oder auch verstanden? :hi:

[greenmile]

Ja, ich habe aber den Sinn nicht so ganz verstanden. Exceptions sind mehr als Sinnvoll, die kannst Du aber einfach abfangen, dafür gibt es Try...Except und schon tauchen die Exceptions nicht mehr auf. Übel sind nur eingebaute Messageboxen, irgendeine Indy Version hatte mal eingebaute Hinweise, bis ich darauf gekommen bin. Insgesamt mag ich persönlich ICS lieber.

[Der schöne Günther]

Finde ich ja auch. Exceptions sind für mich beinnahe die beste Erfindung seit zweilagigen Klopapier. Dass bei einem

Delphi-Quellcode:

Disconnect()

eine Exception geworfen wird wenn nicht alles klappt kann ich noch ansatzweise verstehen.

Aber ich sehe nirgendwo in der Indy-Doku, dass ich hier eine Exception zu erwarten habe. Wenn ich für mich selbst etwas bastele, ist es ok, eine Exception ganz nach oben bis zum Benutzer durchzureichen, vielleicht kann ich spontan mit der Meldung auch etwas anfangen. Aber um die ganze Indy-Geschichte ordentlich verpackt einzusetzen bin ich ja reihenweise am Exceptions essen.

Fazit: Ich bin entweder zu dumm, richtig zu sehen, was ich wann zu erwarten habe, oder es wird einfach nicht deutlich.

[greenmile]

Ich habe kaum bis noch nie eine Doku gelesen, die so detailiert die Vorgehensweise beschreibt. Deshalb kaufe ich, wenn möglich, auch immer mit Source, dann kann ich selbst nachschauen wie manches gelöst ist und was wie passiert/passieren könnte. Ich hatte allerdings schon einige Komponenten bei denen ich lieber nicht hätte nachschauen sollen; so ein Goto im Source macht einem doch Angst ;)

[Codehunter]

Die Indy-Macher haben das Thema Exception eben zum Designprinzip gemacht. Es gibt ja die beliebte ClosedGracefully-Exception, die praktisch im HTTP-Normalbetrieb ständig ausgelöst wird. Da steht dann auch im Indy-Code an der betreffenden Stelle, man möge sich doch bitte jegliche Support-Anfragen dazu verkneifen. Andernfalls solle man geteert und gefedert werden.

An sich ist gegen diese Art der Verwendung von Exceptions ja nichts einzuwenden. Allerdings programmiert kaum jemand anderes so. Ich habe irgendwann die finale 9er Version genommen und komplett von Exception auf Eventhandler umprogrammiert weil mir das Ganze zu umständlich war. Exceptions lassen sich eben schlecht mit RAD vereinbaren, vorallem wenn sie den Normalzustand signalisieren.

Allerdings war ich mit der rein eventbasierten Indy-Version auch nicht sooo zufrieden. Sie haben den Vorteil, dass schon ziemlich viele Protokolle implementiert sind, dass die Serverkomponenten von Haus aus Threads unterstützen und dass die Doku recht umfangreich ist. Der Nachteil bei Indy ist eben leider die Komplexität sowie hier und da verschiedene kleinere Bugs und Unrundigkeiten.

Ich habe allerdings nicht genug mit Netzwerkprogrammierung zu tun, dass ein Umstieg auf ein anderes System wie ICS sich für mich gelohnt hätte.

[sx2008]

Also ich finde der Hauptschwachpunkt bei Indy ist die Klassenhierarchie.
Fast alle TCP-Protokolle (FTP, HTTP, SMTP, ...) sind von TIdTcpClient abgeleitet, was nicht richtig ist.

Die Klassen, die diese Protokolle implementieren dürften nicht abgeleitet sein, sondern müssten ein bidirektionales Streamobjekt benützen.

Sobald eine TCP-Verbindung aufgebaut ist, hat sie nur noch 3 Funktionen: senden, empfangen und schliesen.
Eine geöffnete serielle Schnittstelle hat rein logisch betrachtet genau die gleichen Funktionen.
Wäre Indy besser aufgebaut, dann könnte man z.B. Ketten von Komponenten bilden:

Code:

IdSMTP <--> IdEncyptDecrypt <--> IdMultiplexer <--> IdTCPSocket
IdTelnet <--> IdEncyptDecrypt <--^

In dem Beispiel werden 2 Protokolle verschlüsselt über eine einzige TCP-Verbindung geführt.
Anstelle von TCP könnte man genausogut Bluetooth, Firewire oder Named Pipes verwenden.

Auf jeden Fall sollten der Datentransport und das Protokoll streng voneinander getrennt sein.
Statt Vererbung müsste Indy die Delegation als Prinzip verwenden.

[sh17]

@sx2008 da hast Du Recht, das ist der Schwachpunkt im der Design der Indys - welche Alternative macht es richtig?

[mjustin]

Zitat:

Zitat von sx2008 (Beitrag 1215423)

In dem Beispiel werden 2 Protokolle verschlüsselt über eine einzige TCP-Verbindung geführt.

Wozu soll das gut sein? Welcher Mailserver kann zwischen den Mails, die er empfängt, auch noch Telnet Sitzungen bedienen (auf dem gleichen Socket)?

[sh17]

nein, er meint, da IdTelnet von TCP erbt, könnte man den Kanal von Telnet nicht einfach mal gegen einen anderen austauschen (Telnet z.B. über Names Pipes). Würde in dem Beispiel zwar keinen Sinn machen, theoretisch schon.