SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Tue, 2 Jun 1998 13:53:18 PST8PDT
From:	MDINET!ELMONTE!TomE@mdipo.attmail.com (Emerson, Tom # GPS-MDI)
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com ('Scoug Programming list')
Subject:	SCOUG-Programming: GetLine()

Content Type: text/plain

-----Original Message-----
From: Steven Levine [SMTP:attmail!internet!earthlink.net!steve53]
Subject: SCOUG-Programming: GetLine()

In <35743ECE.4751@peterskye.com>, on 06/02/98
at 10:40 AM, Peter Skye said:

>give you more than one line? Don't you have to check every character of
>your received data for 0Dh, 0Ah, even 0Ch?

Theoretically, yes. But since the client is sending 1 line per send() it
should not happen in this case. Same for end-of-line codes. The FTP
protocol says commands will end with a NL code. Pretty standard for the
Unix world.

Now, it's back to real work...

Interestingly enough, last weekend I picked up what I jokingly refer to
as "another great work of fiction from Microsoft Press..." called "Code
Complete -- a guide to software construction" [the other one I have is
"Writing Solid Code", but to be fair, these books were written BEFORE
windows and GUI's became "mainstream"]

I've only gone through the first few chapters, but already this
discussion can use some of the "pointers" presented thus far. Basically,
this book is targeted at the actual creation of "code", but in order for
you the programmer to be "the best you can be", you have to start with a
solid design, architecture, etc. In this case, we're up against a
somewhat "undefined" aspect of the project -- what EXACTLY must
"getline()" get?

By virtue of the NAME of the function, there is a stong implication that
it gets a LINE of data -- however the definition of a "LINE" hasn't been
given. [at least, not directly within this discussion thread, but rather
indirectly by reference to an RFC for FTP] Steven's definition of a LINE
is a good starting point: some indeterminate amount of text followed by a
character.

Steven: you make the claim "...since the client is sending 1 line per
send()...", but as they say, "this aint necessarilly so...". TCP is
defined as a STREAM oriented protocol. There is no guarantee, in fact,
no way of KNOWING, that the end of a "send()" has been reached just
because a "recv()" returned some non-zero number of characters. It is up
to the two processes at the "ends" of the stream to determine externally
(i.e., by virtue of the RFC) what delineates what was sent via a send()
call. It is also possible that the client may send MORE than one "line"
per send() -- I might want to make a client that AUTOMATICALLY sends an
"ls" command immediately following any "cd" command (for instance, for a
GUI based FTP program, the user double-clicking a folder icon would
generate the pair of commands "cd " and "ls -al" so that the
contents of the directory double-clicked upon would be retreived for
display to the user)

So, to back up to the definition of what "getline()" must do, we need to
consider some alternatives at the "design" level before we haggle over
the details at the "implementation" level.

* Should getline() have a hard-coded internal definition of what
terminates a line, or should that be passed as a parameter? If a
parameter, could there be more than one possible termination character?
[i.e., a "DOS" client might terminate with ascii character 13 only, while
a unix system will use the two-byte combination of ascii characters 13
and 10; yet another system appearently uses ascii character 12]

* Should getline() have a time-based timeout to decide when to "give up"
trying to receive data?

* Should getline() be passed the number of characters to receive and
return at that point, regardless of whether or not the "termination"
character was received? [this makes the routine more general and
re-useable -- for instance, during the actual data-transfer stage, we'll
probably be sending and receiving blocks of, say, 256 characters which
may or may not include any of the terminators described above -- think
"binary mode transfer" OTOH: we now have to pass some sort of "flag" to
the routine so that it takes one of two possible routes: get characters
until a terminator, or get them until "x" number of bytes have been
received]

* Should the above be re-coded in an almost-identical fashion, yet be
called "getdata()" or some such to differentiate that it returns a
specific number of characters rather than an indeterminate number of
characters?

The "Code Complete" book gives a checklist for the "requirements" level
of design. Here are a few choice items which may apply: [note: some of
these may seem like "overkill", but that is because this checklist is
designed more for the entire project, not a "single routine"]

REQUIREMENTS:

[] are all inputs to the system specified, including source, accuracy,
range of values, and frequency?
[] are all the communication interfaces specified, including
handshaking, error-checking, and communications protocols?
[] are all the tasks the user wants to perform specified?
[] is maximum memory specified?
[] is the definition of success included? of failure?

REQUIREMENTS QUALITY:

[] are the requirements written in the users [non-technical] language?
do the users think so?
[actually, since the "users" here are programmers, this might be a "don't
care" item...]
[] do the requirements AVOID specifying the DESIGN
[] is each requirement testable? Will it be possible for independant
testing to determine whether each requirement has been satisfied?

OK, by now I've written enough to glaze a few eyes, so I'll back off and
let the wolves tear into this with this final thought: A comment made in
the book is that if you start with plans for a FIAT, you aren't going to
end up with a ROLLS ROYCE no matter how good a mechanic you are...

Tom Emerson

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 02 | June | 1998 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.