Expletives of Joy!! I must say that I am extremely delighted! You guys are right on the bulls-eye!!! This is the kind of excellence Rebol Tech is famous for! These are just what we needed, and well thought out, too! Hip hip hooray!!! -Galt p.s. Could we also get more than 63 ports per process on Windows? Would help when you are doing a http or proxy server or load-tester. Seriously, I already have a bitchin rebol app that works, but it hits that limit! Real servers have hundreds or thousands of conns going. >===== Original Message From [EMAIL PROTECTED] ===== >On Fri, Aug 25, 2000 at 08:03:31PM +0200, [EMAIL PROTECTED] wrote: >> Hello [EMAIL PROTECTED]! >> >> 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 >[EMAIL PROTECTED]
