[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reading data and attributes
The concern about buffers is, I think, misplaced at this point.
Our concern needs to be focused on the description of buffer
contents and what we are doing with it - both the description and
the contents; in fact, I see the description as including a
reference to where the data is located, whether this is a simple
pointer to a memory block or a buffer managment object being
moot at this point. Yes, decisions need to be made about the
mangement of data storage (and not just for image data), and as
John points out "the devil is in the details". Our deviling details
are in the actual code, but we need to resist designing by code;
lets code by design. Every time I've run into this issue I find
that I have the same experience: at first just shove data into
whatever storage is convenient, then later replace the blunt
instrument with something that has more finesse. I forsee a buffer
management subsystem (class) that is made available to whomever
wants to use it. From this point of view the data description, with
its reference to data storage, would be used something like this:
0. Ap opens/constructs/connects to an Image by providing the
ICL with a File_description (this is the basis for File_Info),
which may be a name (simple or pathname), file descriptor,
input_stream, whatever will produce a connection to a source
of image data. The ICL goes through its Driver interrogation
procedure and gets a valid Image object back. This Image object
contains a Driver object reference within which the Driver has
stored a Pixel_Data description (object) that describes the
image pixel data as it appears in the file (size, type, order,
etc.). This Image object is returned to the Ap.
1. Ap describes the image pixel data it wants. This may or may not
include a description of where it wants the data to be located.
This results in a Pixel_Data description object being attached
to the Image object (note: the Driver object reference is still
in there too, with its own Pixel_Data description for the file).
2. Ap asks the ICL for data: Image.Give_me_data() - this could also
be Image.Give_me_data (Pixel_Data) if the Ap wants to manage pixel
descriptions separately rather than calling methods on the Image
that will do this.
3. The ICL passes the request to the Driver associated with the Image.
However, as an intial scenario for buffer mangement consider this:
the ICL sees that the Pixel_Data does not contain a storage location
for the pixel data so it allocates a buffer of the appropriate size.
Even if the Ap did specify a buffer, then the ICL compares the Ap's
pixel data description against the Driver's and, upon noticing that
a data type transformation will be needed, "pushes" the Ap's buffer
and provides one of its own to hold the raw image data. This push
is of the entire Pixel_Data object, because it may also occur when
the ICL notices that data reordering will be needed. The point is
to pass to the Driver a Pixel_Data description that it can fulfill.
4. The Driver uses its own Pixel_Data description to get the amount of
data specified by the Ap's Pixel_Data description into the buffer
provided by the ICL. Note that I expect the Driver to be able to
get subsets of the entire image because it contains the knowledge of
how to work with the specifics of the file format to do this (if the
Driver decides to read the entire image in and then select portions
out of this memory image, that's its perogative). The Driver returns
the Image object with the fulfilled Pixel_Data (or not, of course).
5. The ICL reconciles the Pixel_Data originally provided by the Ap
against that returned from the Driver, as needed (i.e. if there is
a pushed Pixel_Data object in the image). The ICL returns the Image
object to the Ap with its Pixel_Data request fulfilled.
Note that it is the Image object that is the focus and which is passed
about. The Image object contains Pixel_Data, Driver, etc. objects.
Attributes objects are used just like Image objects, but instead of
having File_Info they have an Attribute_Name; and instead of Pixel_Data
they have Attribute_Value objects (which may contain Attribute_Value
objects ...).
BC
John Ivens wrote:
>
> 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
--
Bradford Castalia Castalia@azstarnet.com
Systems Analyst http://azstarnet.com/~castalia
idaeim 520-624-6629
"Build an image in your mind, fit yourself into it."
The Log of Cyradis, Seeress of Kell.