cf. process_g_code.pde ('talkToHost.get()') ...

A "rs" - should re-wind the send queue back to that item
	+ pull all that lot back off the back-queue and
	  onto the send-queue ...


G1 F1000
G1 X1.06066 Y1.06066 F4000
G1 X9.33434 Y9.33434 F4000
G1 X10.395 Y10.395 F1000
G1 F1000
G1 X11.895 E1.425 F4000
G1 X84.105 E70.0245 F4000
G1 X85.605 E71.4495 F1000
G1 F1000
G1 Y11.895 E72.8745 F4000
G1 Y18 E78.6743 F4000
G1 Y19.5 E80.0993 F1000
G1 F1000

G1 X85.6628 Y19.6397 E80.2429 F1302.32

s 21 Serial Error: checksum mismatch.  Remote (25) not equal to local (87), line received: N21 G1 X85.66282.32*25


N21 G1 X85.6628 Y19.6397 E80.2429 F1302.32*25

rs 21 Serial Error: checksum mismatch.  Remote (25) not equal to local (87), line received: N21 G1 X85.66282.32*25

N21 G1 X85.6628 Y19.6397 E80.2429 F1302.32*25
; writeable - wait ok count is 0, queue 4 resend 0
rs 21 Serial Error: checksum mismatch.  Remote (25) not equal to local (70), line received: N21 G1 X82.32*25
rs 21 Serial Error: checksum mismatch.  Remote (25) not equal to local (70), line received: N21 G1 X82.32*25
N21 G1 X85.6628 Y19.6397 E80.2429 F1302.32*25
N21 G1 X85.6628 Y19.6397 E80.2429 F1302.32*25


	+ FIXME - we need to have a nice "startup" pre-amble, that
	  checks that everything is in sync - and fetches version
	  info etc.
		+ so we don't destroy our first commands to a new reprap ...


* Do we need to send a command for every 'ok' ? is that how the
  queue mgmt works ? cf.:

15830 read(8, "ok\r\nok\r\nok\r\n", 252) = 12

* a 'start' must purge / renumber everything in the queues [!?]

* add a log_printf method to output to the log ;-)

* Accounting for 'OK's and sent lines, and filling the queue
initially with four whatnots ...

* These Errors ? [!?]

* pre-filling the device queue to the right depth:
	+ not done - need to push 4 lines in [!] ...

* We need to log how many lines are on the device ;-)



* Quite nice - strobing 'want write' and 'not want write' etc. :-)



Buffering the entire file is not desirable; it's implemented that way
in repsnapper as a temporary measure only.  Refer to gcdump for
intended libreprap use patterns.


The application is expected to do flow control based on RR_OK receipt
by only ever enqueueing enough messages to fill the device's buffer.
The alternative to this is having enqueue return success/failure and a
configurable maximum host and device buffer size.  I agree that it's
better to have libreprap handle this, especially as we can include
safe defaults for the major firmware this way--and it makes it harder
to use libreprap wrong, too, which is always good.


* The queue does make it easier ... [ I think ]
	+ but - we should manage the queue
	+ so that it is ~always empty ...

/*
I'm not sure there's actually any need for a host buffer, though, as
correctly written application software should respond effectively
instantly to space becoming available in the device buffer.
*/

	- Good ! :-) - bin that buffer [!] ...

* No host buffers == no priority queues, can leave prio bits I guess.
	+ several command(s) being written - do it async ?
	+

* What API basically do we want:

	+ bool wants_write();
	+ void write_stuff() ...
	+ callbacks:
x		+ read_result ...
		+ please_write_more
x		+ error: disconnect
		+ [log data]
		+ [hidden] - resend

	+ get_buffer_status [etc.]

* I/O coupling:
	+ rr_dev_set_need_write_cb ();
	+ 

/* start:
	for (int i = 0; i < recv_size; i++)
		more_cb() ... ?


"\r\n" was sent because that was what the protocol documentation I
referred to specified.  For protocols that expect only '\n', please do
correct that, but be sure not to break any protocols that expect both.

I suppose pausing the send queues is somewhat useful, though generally
you're not meant to have very much data sitting in them.  Then again,
it's always best to be as responsive as possible, and a single G code
can easily occupy the machine for several seconds--so I have no
objection to supporting it.  I don't know what you mean by "how deep
that should be."  Perhaps you refer to the configurable buffer sizes I
mentioned above?

Using the alternative flow control approach described above, it
shouldn't be necessary to do any manual processing of reply
confirmations, let alone pausing beyond user pause requests.



- writable:
	+ do we do all writes in response to polling for write-ability ?
