From: Dave (dfisher_at_pophost.com)
Date: 2002-03-19 12:06:21
On Mon, 18 Mar 2002 15:34:54 -0000, sleeper75se wrote:
>Hi John,
>
>here are some quick comments and opinions on what is missing in your
>design. I hope you find them useful:
>
>* I think some of these class names, such
>as "Interface", "Device", "FileReader", "USB", "Sensor" etc are too
>generic. They should be more descriptive and perhaps use a common
>prefix to group them together, avoiding name-clashes as the program
>grows in size. Examples: BioSensor and BioInputDevice. "Bio" is just
>a suggestion, something else might sound better.
Did you look at what I had done? That is the prefix I used also, and it seems
to work well. If we choose C++, then I think we should situate this within a
namespace. Some suggestions::
openeeg, or
oe, or
oeeg,
or ???
That way we can avoid collision with other libraries we are using.
>* Some names can't be written in code (Java or C++ anyway). ("HAL-4"
>and "Modular EEG")
>
>* Opinion: Shouldn't "respiration" and "temperature" sensors have
>three letter designators as well?
>
>A device that logs temperature is called "thermograph" and a device
>that measures breathing rate is called "pneumograph".
>Using the same "E" as in EEG, ECG and EMG, we would
>get "electrothermograph" and "electropneumograph" (ETG and EPG).
I would argue against this, simply because the choice is being made out of a
sense of comformity to structure, and not out of a sense of need for clarity.
ETG and EPG are not used within the medical community, and I would find myself
constantly having to remember exactly what they are and what they mean during
the coding process, whereas the following objects:
SensorTemperature (or SensorTemp, if you really want an abbreviation)
SensorRespiration (or SensorResp)
SensorEMG
SensorEEG
SensorGSR,
and so forth are much clearer and understandable.
Please do not sacrifice clarity for structure.
>* You need to define a class for managing data in memory. It may also
>encapsulate (control) a file manager object.
What data are you referring to here?
>* The sensor objects produce data. How about defining some data
>streams for that data? Perhaps EEGDataStream, EMGDataStream etc.
>inheriting from BioDataStream, inheriting from a standard class.
What might be nice is that if we abstract this out far enough, the underlying
implementations can be different depending on our varying needs. That would
mean, however, that we would want to create a base class to define the basic
behavior of the object, but not necessarily have that class inherit from a
standard stream class. That would be up to a sub-classing expression of the
base class. In this way, the actual mechanics of the sensor data transport can
be different based on the interests of the application. I'm going to have to
think on this more, though, to determine exactly what the base class will need
to define in terms of virtual methods to define the kind of behavior we want to
see in the streaming data (perhaps nothing more than OpenDataStream(),
ReadDataStream(), WriteDataStream(), and CloseDataStream() methods. This way,
the underlying transport can be anything from sockets to shared memory to
whatever. Each sensor can inherit this class since each sensor will have one,
and only one, data stream.
>* As for the user interface and signal-processing sections: I have
>not given them much thought yet ...
>It might be beneficial to limit the design scope for now, to include
>only data types, input, management and file storage as it forms the
>foundation of our "house". The feedback and signal processing parts
>can be saved for later. Focusing on one thing at a time usually
>produces better results too.
>
I agree. I think it would be helpful if we start thinking in terms of multiple
API's for the project. For example, we have the whole API which will be
responsible for the interface to the devices -- meaning, the handling of data
to (control information) and from (sensor data) the devices. Another API could
be biofeedback protocols. Then you would have applications built from these,
which is where issues of user interfaces would reside. So, for right now, we
are focusing on the API responsible for managing the devices and data to/from
those devices.
>By the way, we should find some coding standard to follow. I suggest
>this one: http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
I am also in favor of coding standards, but not to the extent of some. While I
feel an overall agreement to style is important (such as block indentations,
use of braces, capitalizations, etc.), it can go too far when enforcing
nit-picky details for things like paranthesis use and spaces (i.e., foo(arg) as
opposes to foo( arg ) ) and so forth. So I would suggest some global
standards, but not get drowned in the details. 'Course, you referred to Java
above, which I cannot speak to anyway. :) But, since language is still in
question, are we really ready for this kind of discussion? I'm am still hoping
for some flash of inspritation on the question of language, which, so far, has
not happened. This is a tough one given our disperate backgrounds.
Dave.
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:43 BST