Jetsoni, guppy, I do not oppose a patch of eggdrop's rather strange idea of considering blank lines as "end-of-connection" markers.
The patch proposed here, however, will break many scripts. Personally, I don't mind such a break, but only if the patch brings an improvement and the consequenses are carefully reviewed.
Actually, in the previous century Ernst used a patch which changed the "end-of-line" marker from a blank line to something like "**EOF**".
As a minimum, a patch MUST include a PROPER and WELL DEFINED "end-of-connection" marker. Jetsoni, what marker have you introduced in your patch?
Currently, blank lines are not send to eggdrop's [control]. When a connection terminates, a blank line is send to eggdrop's [control] to mark an "end of connection". Properly written scripts test on this "end-of-connection" marker.
When writing an HTTP script one may encounter the following major headache. HTTP seperates a HTTP head from a HTTP body with a blank line. An eggdrop script, parsing an HTTP POST, will thus have difficulty seperating head and body.
Additionally, lines are only send to eggdrop's [control] after an "end-of-line" marker. HTTP POST's not always contain an "end-of-line".
Subsequently, posted data is not send to eggdrop's [control] and the connection may hang until either part terminates the connection.
(Read
http://forum.egghelp.org/viewtopic.php? ... forum=2&11 )
Although ways of circumventing the above are possible, they give major headache and increase CPU usage substantially.
A proposal for a patch is to mimic TCL's sockets behaviour half or fully:
- blank lines do not indicate an "end-of-connection" and are send to eggdrop's [control] like any other line.
- a command to check for an "end-of-connection", something like [eoc $idx], similar to TCL's [eof] command. Return "1" if "end-of-connection", "0" otherwise.
- a command to read a number of bytes from the socket, something like [readidx $idx $numbytes], similar to TCL's [read]. Return "1" upon successfull read, "0" otherwise and leave bytes on the socket.
- commands like TCL's [gets] and [fblocked] may be needed (?).
One may ask: why not use TCL sockets right away?
- By sticking to eggdrop's commands, dependencies on (future changes in) TCL sockets are elimated
- TCL's [fileevent] is only triggered once every 200 ms or so by eggdrop's loop, which makes processing of HTTP's head + body take 2 seconds or more. This may be circumvented by reading all data available on the socket, but is a bit awkward compared to eggdrop's [control].
- eggdrop's commands related to $idx (and not sock#), like [dcclist], [putdcc], [putidx] etc. can still be used in scripts.
- Personal observation: eggdrop is more sensitive to errors/bugs in scripted TCL's sockets (i,e, eggdrop crashes easily when a bug/mistake is made
using TCL's sockets).
<font size=-1>[ This Message was edited by: egghead on 2002-02-20 20:35 ]</font>