To Do List:
- Logo.
- Security (SYS, DF, KERBEROS, others) in a consistent and flexible way
(txrxAuth arguments). Setup of security should be per connection
not per protocol thus it should be associated to the buffer not to
the protocol. This is a good argument to split the protocol from
the buffers.
- Documentation: manual pages using troff macros - use current html
pages.
- Sample applications: distributed shared computing environment (rproc),
WebNFS client,
imaging application - with a prototype workflow
engine written in Tcl and downloadable user agents,
bind service (useful for UNIX impaired people that
run RPC servers). Graphical front ends to
bind/portmapper/mount/other services.
- Documentation: paper introducing the extension and tutorial
on how to use it.
- Add batching to RPC's. Given the buffering
model, is is easy to send multiple RPC's without
expecting an answer then wait for a reply on a certain
call. Proposed name: txrxCallFast :-).
- Timing experiment vs. RPC generated code. A C-client/Tcl-server
ran about 10 times slower than a C-client/C-server on the same
machine. The test involved 200k calls, minimal processing on the server -
upkeep of an associative array of ints with integer keys. Time using C/C was
9 seconds. Time using C/Tcl was 91 seconds. If used over a WAN processing
time is no longer a concern.
- Expose the send/receive interface txrxSend/txrxReceive to
allow other protocols to be developed.
- Proper Tcl widget behavior using Preserve/EventuallyFree.
- Split buffer mechanism from protocol. This allows servers to
handle multiple interactions at a time using the event mechanism.
Future items of interest:
- C interface to buffer management - convert/create/free C data
structures, similar to XDR functionality. One can argue this is not
required as C developers have rpcgen to use.
- Missing elementary types: hyper, quad. Machines with native support
of these types are scarce and most client type machines (i.e. PC's) will
not support these for the next couple of years.
- Parser needs to understand common type extensions:
char (int), netobj (opaque<1024>), byte (just another name for opaque).
- Sending elementary types should be allowable without a protocol.
This is doable right now using type codes but it should be feasible using
type names.
- Change CellType to be SymbolType -- the two enums have the same elements
and the same function.
- Procedure number 0 should always exists in a protocol
if not defined explicitly by the protocol as: void __null(void) = 0;