> Whomever you ask, I hope they'll reply here on the list so we all
> can benefit from the info! This is something I've wanted to know
> more about (as well as UDP with REBOL) for some time. Thanks, /Russ
>
>> ----- At 02:22 PM 1/9/2000 +0200, you wrote: <snip> BTW, I have
>> spent some time over the last holidays studying how protocol
>> handlers work, because I need to write one. I still need some
>> clarifications on the port flags, and the meaning of the fields in
>> port/state... this could save me some time. :-) Can I ask to you,
>> Jeff, or should I ask to Sterling? Regards, Gabriele.
Well, lessee.. generally, the state object relates to presenting the
data a port contains or fetches as a serialized set of values.
state/tail is the end of the data, what should be reported when you do
LENGTH? on a port. Similarly, state/index is like a series
index. This value gets bumped when you call NEXT on the port. When
the state/index = state/tail then the port is at the tail, and TAIL?
port will return true. The state/flags there correspond to the
capabilities of the port. At some point the doc team will cover ports
and clarify the other fields. The time I've written handlers I never
really needed to touch most of the values in the state object.
(Sometimes you can't set these field when with some protocols you
can't know what the tail of the data is...) To look at a protocol
that messes with the tail and index members of the state object check
out pop. Typically, the open sequence will set the state variables.
Now the port flags change the functional properties of the ports.
With network ports it generally comes down to either pass-thru ports
or direct-ports (all the built in protocol port handlers are one or
the other). To see the differences in behavior try playing with the
script listed below. I know that's hand waiving, but I didn't
implement the port mechanism so I don't want to say anything incorrect
about them. Give this a play, though. Hope I've been helpful. (-:
-jeff
--------------------------------------------
REBOL [
Title: "Port Tester"
Purpose: {
Illustrates the different port mechanisms of
"direct ports", vs. "pass-thru" ports.
Discover the differences by playing with
two dummy ports.
}
]
tst-port: make root-protocol [
init: func [port spec][print "Init" 1]
open: func [port][
print "open"
port/state/flags: port/state/flags or port-flags 2
]
close: func [port][print "close" 3]
write: func [port][print "write" 4]
read: func [port][print "read" 5]
copy: func [port][print "copy" 6]
insert: func [port][print "insert" 7]
pick: func [port][print "pick" 8]
]
foreach [flags name] reduce [
system/standard/port-flags/direct 'dport
system/standard/port-flags/pass-thru 'pport
][
make tst-port compose [
port-flags: (flags)
scheme: (to-lit-word name)
;-arbitrary port number assigned below
net-utils/net-install (name) self (2000 + random 1000)
]
]
print #DP dp: open dport://
print #PP pp: open pport://
;- Now notice the different results of
; using COPY, INSERT, PICK, and CLOSE on
; the above ports.
;
;- also, try: read dport://
; vs: read pport://
;
;- and: write dport:// #
; vs: write pport:// #
;
; Pass-thru ports return results from different
; phases. Pass-thru goes directly to named function
; with out buffering...
