// Q: question
// C: comment

// Ultimately, this should be abstracted to a multipurpose 
// ASIMET driver capable of talking to any ASIMET instrument.
// The driver configuration options would need to include the 
// module type, communication mode (RS232/485), and address.
// The driver should also support a RS485 multidrop configuration,
// and so may need to be able to determine which instruments 
// are installed on the RS485 bus.
// It may be requested that several of these instruments
// (in an RS485 multidrop configuration) be treated as a
// single instrument.


// Q: As I understand it, all of the messages to the SK are 
//	placed in a queue...does that mean that I have to wait
//	for all pending messages to complete before I can 
//	execute a command? This appears to be the case. Perhaps
//	the CommandParser should spin a new thread to process each
//	incoming message and manage concurrency issues for each
//	message recipient. On the one hand, we don't want to have
//	multiple copies of objects manipulating instrument hardware;
//	on the other, we don't want to wait several minutes to send
//	instructions to an instrument just because another one is
//	with a long sample cycle is running.

// Q: What programatic interface is provided to enable access
// 	other instrument functions? Although there is a configure
//	method, it seems designed to try to do all configuration
//	at one go. *The driver should expose instrument functions
//	without imposing policies*...For example,getting a sample, 
//	setting the time, or changing an address tag are examples 
//	of instrument functions, but the driver should not make us
//	set the time if all we really want to do is change the 
//	address tag. Along these lines, why is sample acquisition
// 	different from any other function provided by an instrument? 
//	Why not use an interface with a function like 
//	do(int funcID, Object argumentBlob)
//	to access instrument functions exposed by the driver?
//	The caller would have to know what arguments are required
// 	and the driver would be responsible for checking the
//	validity of the arguments.

// Q: In the OASIS paradigm, drivers are able to do perform 
//	processing on persistent data structures (keeping a running
//	average, for example). While I don't think it should be
//	up to the driver to do such processing tasks, is there
//	a mechanism that would allow such intermediate processing 
//	to take place? If this is a client application of some kind,
//	how is it notified of instrumentation faults, etc.?

// Q: How are drivers synchronized with one another? If I need to
//	run a pump for 3 minutues, then take a sample, then turn off
//	the pump, wait and take another sample, how is this done?

// Q: It looks like CommandParser catches any exceptions that occur 
//	during sampling...What is NMC's scheme for indicating instrument
//	errors? If we want to try to handle these errors, that will need
//	to be done by the driver.

// C: OASIS has a different record type for each instrument,
//    as well as a type for error records. In this way, errors are 
//    treated like any other data. I imagine that NMC makes
//    a distinction...where do errors go?

// C: The errors that are most important to handle are 
//    - instrument fails to wake up or respond
//   	- instrument responds, but provides partial data
//    - instrument responds, but provides no data
//    - instrument responds, but provides invalid data
//	- instrument spews (possibly binary) garbage or 
//	  other unexpected message; this may confuse the
//	  driver or slip through as part of the data and
//	  confuse processing utilities downstream.
//	- dynamic memory allocation call fails
//    - instrument hangs indefinitely
//
//    OASIS, does not have the resources to intellegently
//    catch or handle most of these errors, and so may
//    only log them.
		
// Q: Why two write methods? just wrappers for ostream.write()?

// Q: When is power applied to the instrument? What is responsible
//    for managing the instrument power?

// C: Recommend putting timeouts, retries as arguments
//    to read/write routines. This would allow the same
//	method to use different timings during different phases
//	of the sampling cycle.

// C: May want to offer inclusive/exclusive option on calls to 
// 	readUntil() to save/discard the terminator

// Q: Why is data copied into a new buffer before returning it?
//	Why not return sampleBuf?

// C: StdInstrumentDriver::configure() makes some assumptions that
//	will not be true for many instruments: 
//	- The ASIMET does not wait for end of line to execute its 
//	  commands.
//	- It echoes commands, sometimes with, sometimes w/o eol.

// C:	To make the ASIMET HRH driver work, it was necessary to
//	write a new getSample() method and override the poll() so 
//	that it calls the new getSample(). It is not reasonable to 
//	assume that the getSample() method will not change per 
//	instrument; it will be different for most instruments. 
//	The polling logic may be different as well...
//	It might make more sense to lump the polling logic into 
//	getSample() and make/allow it to be overridden as part of
//	the instrument interface.
 
// Q: I have seen several places (e.g. configure, flushInput,
//	readUntil) where something tests 
//    <some InputStream object>.available()>0
//	I have also read in the Java API that 
//	InputStream.available() always returns 0...
//	How does this work?