"Dennis" <marianndkc@home3.gvdnet.dk> wrote in message
news:4420fb0b$1@newsgroups.borland.com...
> I understood it as string based response codes were no
> good in the client. I understood the help such that
> IdTCPClient1.SendCmd('Hello', -1); would accept any
> return value. 'OK' is any return value to me.
No, it is not. Your understanding of the system is still not correct, so
let me try to explain it another way.
'OK' is a string. SendCmd() CANNOT receive a STRING response code AT ALL
when using TIdTCPClient directly! It can ONLY receive NUMERIC response
codes. When you call SendCmd(..., -1), you are telling the NUMERIC version
of SendCmd(), not the STRING version, to accept any NUMERIC response code,
not any STRING response code! And you CANNOT use the STRING version of
SendCmd() when using TIdTCPClient directly because TIdTCPClient uses
TIdReplyRFC, which only accepts NUMBERS, not STRINGS.
> It is very counter intuitive to me that like named components such
> as TIdTCPClient and TIdTCPServer and TIdCmdTCPServer and
> TIdCmdTCPClient does not work together as a pair.
They are very intuitive, and do work as pairs. You just are not using them
properly.
> Why are they designed that way?
The names have nothing to do with the pairings. The names are based on
their individual functionalities, as they should be. TIdTCPClient and
TIdTCPServer are basic TCP sockets. TIdCmdTCPClient and TIdCmdTCPServer, on
the other hand, each utilize the CommandHandlers collection to automate the
processing of commands that they receive. TIdTCPClient is paired with
TIdCmdTCPServer in situations where the client sends commands to the server
and the server sends back responses. TIdCmdTCPClient is paired with
TIdTCPServer in situations where the server sends commands to the client and
the client sends back responses.
> It is also counter intuitive that IdTCPClient1.SendCmd; accepts
> string response codes when it does not work with them.
SendCmd() is implemented generically at the connection level. It is the
responsibility of each descendant class to decide how received responses are
actually processed. Most RFC-based protocols use numbers, not strings, for
response codes. Most of the Indy components that derive from TIdTCPClient
use the numeric version of SendCmd(). Only TIdPOP3 and TIdIMAP4 use the
string version of SendCmd() since those are protocols which use strings
instead of numbers for response codes.
SendCmd(), regardless of whether the numeric or string version, is dependant
on the capabilities of the particular TIdReply class that the component is
using to parse the raw response data. Most of the components use TIdReply
classes that are derived from TIdReplyRFC, and thus are based on numeric
codes. TIdReplyPOP3 and TIdReplyIMAP4, on the other hand, derive from
TIdReply directly instead of TIdReplyRFC, so that they can operate on
strings instead of numbers.
Gambit
