Reading data and attributes

[John Ivens <jivens@hindmost.LPL.Arizona.EDU>]

Steps in reading Data:

1. APP allocates space for a buffer.
2. APP asks ICL to Give_me_data(format,buffer)
3. ICL knows which driver to ask, and asks it Give_me_data()
4. DRIVER allocates space for its own buffer
5. DRIVER gives data to ICL return_data(format,driverbuffer)
6. The ICL moves the data in the driver_buffer into buffer
7. The ICL tells the APP that it has valid data (returns)

Notes:  The driver returns ALL of the core data in a buffer in the
format that the data was stored in during step 5.  The ICL takes this
core data and munges it into the format desired by the APP during step
6.  The buffer space is allocated by the APP, and passed to the ICL. 
The ICL never allocates space.

The driver was determined by the ICL Interrogator.

At some later date provision needs to be built into the system to
request only portions of the data.  Whether or not this filtering would
happen at the driver level or the ICL level is not known at this point.

Steps in reading an Attribute (trickier):

1. APP allocates space for an attribute, and then asks ICL for a
generalized attribute value in a particular format
Give_me_attribute(APP_Attr, APP_Buffer, APP_Format)
2. The ICL asks the DICTIONARY to translate the generalized attribute
into a specific attribute that the driver knows about Driver_Attr =
Translate_attribute(APP_Attr, Driver, ICL_Format)
3. Armed with an attribute that the driver can understand, ICL requests
the actual value associated with that attribute from the driver
Driver_Val = Give_me_attribute(Driver_Attr)
4. At this point, the ICL has the value in some agreed upon format that
the driver knows about, probably char *.  This format will handle sets,
sequences, arrays.  Now the trick is to get the value into the format
that the APP wants.  There probably needs to be some kind of translator
object, maybe the DICTIONARY, or maybe something else, that knows these
formats and how to munge them.  Lets assume that there is another
object, FORMATTER, that knows how to translate formats.  So ICL asks the
formatter to format the data according to what the APP wants. 
Format_Attr_Val(Driver_Val, Driver, Driver_Format, APP_Format,
APP_Buffer)
5. The ICL tells the APP that it has valid data (returns)

Notes:  The handling of sets, arrays, sequences needs to be discussed. 
Also, in the ICL exceptions should be raised if something goes wrong,
and the driver will probably send back errors as integers which will be
checked by the ICL. If the ICL discovers a driver error it will raise an
exception to be caught by the APP.

Dyer's comments:

I agree with everything you have written, except:

There should be the possibility of the APP not providing a buffer.
That is, the APP should be able to say either Give_me_data(format)
or Give_me_data(format,NULL) and the ICL will allocate space and
return a pointer to it.


Additional notes:

It seems to me, as with the attribute stuff, that there
will be a seperate object (format_translator) that will translate
the raw driver data into requested format data.

Some of the objects identified so far (and possible patterns):

ICL_image_object                             (Composite)
  ICL_interrogator_object                    (Mediator)
  ICL_data_format_translator_factory_object  (Factory)
    ICL_data_format_translator_object
  ICL_dictionary_object                      (Strategy)
  ICL_attribute_formatter_factory_object     (Factory)
    ICL_attribute_formatter_object

Mini_Driver_object
  Maxi_driver_object

An attribute will probably be an object too at some point
along the way.  I don't know if the driver should return
an object when an attribute is requested, ?, probably.

-- 
When I use a word it means just what | John Ivens
I choose it to mean - neither more   | Principal Programmer
nor less.                            | Cassini VIMS
-- Humpty Dumpty                     | (520) 621-7301