Socket SEND()

[Fairlight]

Y'all catch dis heeyah?  Nancy Palmquist been jivin' 'bout like:

> Why wouldn't the socketclose() wait until the transaction is complete to
> happen?

Why should it?  If I tell something to close, it better darned well close
how I tell it to and when I tell it to.  Programming isn't supposed to be
like Windows...  "Are you sure you want to close the socket?"  "Are you
ABSOLUTELY POSITIVE you want to close the socket?"  "There's outstanding
data that may not be accounted for, you know.  Perhaps you should sit down,
take a stress pill, and rethink closing the socket?"

NO, CLOSE THE BLOODY SOCKET AS INSTRUCTED!  :) :) :) :) :)

There are any number of valid reasons one might wish to abort a connection
before a transaction is complete.  Authorisation failure, excessive
retries, and the list goes on.  Why would one wish to take away the
ability to do something perfectly legitimate because one person couldn't
be bothered to learn protocol design and sanity checking techniques for
networking?

> I always expect one command to complete before the next command is
> executed and for filePro to handle this kind of thing.  I find it very
> difficult to try to program with this kind of silliness.

It's not silliness.  It's called networking.  If I walk into an accounting
office and tell them all those numbers and books are silly, exactly how do
you figure they'd react?  They're the ones with the clue in that scenario,
as they do it all the time.  Same here--you don't do it all the time, some
of us do.  There's nothing "silly" about it.  It's life with networking,
period.  Silliness doesn't enter into it.

Good grief, be glad you're merely dealing with TCP, not UDP.  You don't
even want to hazard a wild guess as to what's entailed in -that-.

> If I wanted to handle all the communications myself, I would not use
> filePro.  I think filePro should handle the I/O correctly without my
> help, just like it does when I write or read a file, it handles locks,
> updates indexes and generally makes it happen correctly.

You're making the assumption it should know to do something better than it
does.  That's an unfounded fallacy.  It falls under business rules, which
should be dictated by the application developer, not by the vendor.

* The socket should possibly be closed anyway.

* The (last) transmission should possibly be resent.

[Insert list of half a dozen or more things that might be done.]

You'd have the vendor use their Superfunkymagicpsychicpowers to figure out
what you want, and pray it's what everyone wants/needs as well?  That's not
the way it works.

Network coding "without your help" isn't possible--not properly, anyway.
It's a design decision properly left to the developer.  What you're asking
for is like saying fP should automatically get your AR/AP ledgers correct
because you wish it so.  There are variable business rules involved in
which fP-Tech has -no- business interfering.  And to their credit, they
don't.  Mark your calendars, because this is one of the few times I've been
able to honestly side with fP-Tech on something for -not- dumbing it down.

As for not using filePro if you wanted to handle all the networking code
yourself, well I find that statement to be just plain silly.  For one,
fP is -not- (IMNSHO) a valid platform for networking in general.  The
distinctive clash between the event-driven model and how networking flow
is usually laid out means that you're -generally- doing something very
un-filePro-like in order to do your networking -anyway-.  This is less true
of clients, but most assuredly true of servers.  

With a server, you're essentially having to lock the fP processing into a
purpose-specific task for which it was never designed, and which poorly
fits the usual fP logic flow.  Sure, the functionality is there nowadays,
but fP was never actually -designed- for this kind of use--and it shows.
It's like using the US Postal Service to move between two houses.  Sure,
you can pay postage on every item in your house and have it shipped, but is
it -really- the best or even near the most effective way to go about the
project?  No.

You're going to have to handle your networking properly no matter -what-
language you use.  If it's inconvenient to learn how to do it properly,
there are hundreds of people out there that write network code that can do
it for you.  There are maybe three that I can think of that might be able
to get it right purely in fP, but they exist as well.  And, by the way, one
of those three says it's a such a lousy platform for networking he wouldn't
even bother trying under that platform unless there was a LOT of money in
it. :)

> >> I really appreciate any help, even if it does not relate to the
> >> filepro sockets.  You were all very helpful last time.

I'm not seeing very much appreciation of Ken's answers.  I'm seeing a lot
of complaining that networking requires some degree of developer knowledge,
intervention and decent design to get correct.  That's not fP-Tech's fault.
It's a reality in any language, on any platform.  The cold, hard truth
is that networking can not and should not be dumbed down to the level fP
usually dumbs things down.  Period.

<Matrix> Do not try to get your networking solution to be fed to you on a
silver spoon, for that is impossible.  Instead, realise the truth:  There
is no silver networking spoon. </Matrix>

mark->