From: rasure@borris.eece.unm.edu (John Rasure)
Newsgroups: comp.soft-sys.khoros
Subject: Re: KHOROS/VIFF 2.0 Questions
Date: 16 Oct 92 21:02:25 GMT
Article-I.D.: pprg.41033


In "KHOROS/VIFF 2.0 Questions", Lance Al-Rawi writes:
+ The new document on VIFF 2.0, "Volume II, Chapter 10" 
+ sufficiently introduces and specifies VIFF 2.0 to the KHOROS
+ community.  However, having now studied the document we 
+ have formulated a few questions primarily concerned with
+ the notion of abstract or object oriented data access
+ via the data services library functions.

After the alpha release, I will put out a data services document so that
you can get more information.

+ 
+ Assumptions: KHOROS/VIFF 1.0 provided DIRECT access to the
+ entire viff structure (xvimage) to applications.  It is stated
+ and implied in the document that KHOROS/VIFF 2.0 will strongly 
+ discourage such direct access.  Access to VIFF 2.0 data
+ segments and attributes will be carried out indirectly
+ via data services library functions.  However, section
+ A.6 VIFF POINTERS, seems to imply that a memory resident
+ VIFF 2.0 will be sucked into a data structure similar
+ to the xvimage.  (typedef viff in KHOROS 2.0) The 
+ difference being that direct access will not be permitted.

Hmmmm.  The information that is missing is that the pointers aren't
necessarily to malloced memory ... that are in effect pointers to
some sort of data transport (shared memory, directly in to paged
virtual memory, socket, stream, file).

+ 
+ Assuming the above assumptions are correct it would seem
+ that following scenarios would be possible.  Which
+ if any of these scenarios are accurate, and if
+ none of the following scenarios are accurate please
+ enlighten us.
+ 
+ Scenario 1: Indirect data access (e.g. Read/Write of
+ 	    some or all of the Value Data Segment) will 
+ 	    result in a separate/new copy of data.

No.  There will only be copies when the data transport is non-permanent
and a copy MUST be created.   Depending on the transport and the size
of the access, there may be some buffering (a partial copy).

+ 
+ Scenario 2: Indirect data access could result in
+ 	    a return object containing pointer(s)
+ 	    to the requested data.  In this case
+ 	    the requested data may not be contiguous.

No.  The application programmer will be given contiguos data of the
amount desired in the dimensionality desired.  (point, line, plane, volume)

+  
+ Scenario 3: Indirect data access could result in
+ 	    a reorientation or transformation
+ 	    of the data so that the application
+ 	    can access the data in the most
+ 	    appropriate manner.  In this case
+ 	    the requested data should be able
+ 	    to be contiguous.

This will be possible.  Actually the access of data can perform the following
transformations on the data:  type conversion, interpolation, extrapolation,
scaling, normalization, orientation, mapping.

+ 
+ 	NOTE: "Contiguous" refers to the fact that
+ 	      multiple data lines, planes, or volumes 
+ 	      are contained in one big contiguous
+ 	      chunk of memory containing one or
+ 	      more of these logical data objects.
+ 	      
+ 
+ Scenario 1 is entirely indirect and therefore a write back
+ to viff (viff data structure) function would be necessary. 
+ 
+ Scenario 2 and Scenario 3 would not require a write back
+ function since the access to the data segment would
+ be direct after the prescribed indirect access function
+ had been called.
+ 
+ Thank you in advance for your attention to these questions.

It seems you are pretty smart about how things like this might work.
Once I have a document solid enough to read, I will make it available.

John Rasure

+ 
+ Lance Al-Rawi
+ lalrawi@ucsd.edu
End of message from Lance Al-Rawi