
An important gotcha to watch out for:

a) Because of the producer/consumer fifo design, it is possible to
fill the queues with a bunch of commands at once.

b) You may be tempted to build 'complex' commands that require issuing
other commands in order to complete their task.

For example (using NNTP), you may want to issue an 'ARTICLE 23'
command for a particular newsgroup, but since it's not the current
group, you need to issue a 'GROUP xxx' command to switch before
you can issue the ARTICLE command.  This would result in two
commands being pushed on the queue, with the result of the ARTICLE
command depending on the result of the GROUP command.

       <==
fifo: [<GROUP command consumer> <ARTICLE command consumer>]

This will work, but only in the case where there were no other
commands previously queued up.  If there had been other commands,
then the GROUP and ARTICLE consumers would have gone on the end
of the queue!

fifo: [<QUIT command consumer> <GROUP command consumer> <ARTICLE command consumer>]

And in this particular case, the QUIT command would have closed the
connection!

Moral: If you intend to 'saturate' a client with a bunch of
commands, realize that you can't use sub-commands.

==================================================

Some additions to consumer.typical_internet_client may help this
problem.  It is now possible to control the maximum number of
'outstanding' commands... in which case it might be safe
to toy with the command queue, but I haven't thought enough
about it yet.


