[REBOL] CGI: reading POST-method data with read-io Re:(4)
From: holger:rebol at: 25-Aug-2000 16:23
On Fri, Aug 25, 2000 at 08:03:31PM +0200, [g--santilli--tiscalinet--it] wrote:
> Hello [petr--krenzelok--trz--cz]!
>
> You need to use READ-IO when you a) want the raw data and b) don't
> want to wait for the remote part to close the port. COPY/PART had
> a similar functionality on /BINARY TCP ports, but it still waited
> if there were no data in the port. Now you can just use COPY or
> COPY/PART, because it no more waits for data.
Please wait for the next experimental build (i.e. a version AFTER
Core 2.4.34, View 0.10.25 or Command 0.6.12) before publically releasing
any scripts that use the new non-blocking features in REBOL, because
we need to change the behavior (again), for better compatibility with
older scripts, and to avoid future legacy problems, This change will
break scripts that rely on the behavior in the current exp-build.
The changes are: copy on TCP ports opened without refinements will work
the way it used to originally (i.e. block if there is no data). If you
don't want copy to block then use /no-wait on the open call. This means
instead of a /wait refinement there will be a /no-wait refinement,
and the default behavior will be reversed compared to the current
exp-build, and thus will be the same way it used to be in Core <= 2.3
(blocking).
The main reason is that with this change scripts which loop on copy
until it returns none will continue to work on new versions of REBOL,
without adapting the script.
Also, if there is no data then copy will return an empty series, not
none, as it does in current exp-builds, allowing you to distinguish the
no data available yet, would block
case from an end of stream, i.e.
the peer closing the connection (for which copy will still return none).
There will also be some changes to wait to make it more useful, e.g.
wait [0 port] will poll the port (i.e. return the port if there is
data, and none otherwise). This also works with multiple ports.
Old versions of Core already used to do this on some platforms,
somewhat inofficially, but current versions don't. It will become
an official feature on all platforms starting with the next
experimental build. There will also be a new "/all" refinement
to wait which causes wait to return a block of all ports that have
data waiting (instead of returning just one port). This allows you
to write your own scheduler (e.g. round-robin) for handling incoming
data on a multiplexed server written in REBOL.
We are also planning other enhancements to wait and ports in general
in the future, to make it easier to handle interactive, asynchronous
connections, to support asynchronous sending, asynchronous connecting,
asynchronous accepting of connections, asynchronous UDP operation,
and to simplify the handling of multiple connections at the same time,
e.g. for downloads in the background and for multiplexed web/ftp
servers. Lots of good stuff ahead :).
Please avoid using read-io whenever possible. It is a very low-level
function that exposes your script to operating system-dependent
oddities. For instance the amount of data typically returned may vary
with the operating system, making testing more difficult for you. You
also lose the convenience of line feed conversion etc., which may cause
unexpected problems with your script when moving between Windows and
Unix machines. "Normal" port functions in REBOL (copy, insert etc.)
do these things automatically for you.
We realize that in the past some shortcomings in the "normal" port
functions (in particular copy blocking) have prevented you from doing
some useful things, and sometimes read-io seemed to help, but these
issues should be resolved in the next exp builds, and then the use of
read-io will be discouraged even more than it is now.
And just in case you are wondering, those new port features together with
work on some additional enhancements in VID are the reasons why the
new exp build for View we promised earlier is not out yet -- sorry for
that delay. RSN, really...
--
Holger Kruse
[holger--rebol--com]