Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[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]