Our The focus in the API
is the user view of access. While the API does provide varied facilities to
give the user the ability to effectively architect his or her application, it
does not address the tool level efficiency concerns such as time-based
incremental load of the data, and/or predicting or learning the user access. It
is left up to implementers
implementers to make
this as easy and seamless as possible on the user. To make this easy on tools,
the API provides an initialization routine where the user specifies access type
and design scope. The user should be primarily concerned with the API specified
here, and efficiency issues are dealt with behind the scenes.
#define vpiAccess LimitedInteractive vpiAccessLimitedInteractive 830 /*
interactive */
Our The usage here in the
read API is of either:
Note that loading the object means loading the object from a
database into memory, or marking it for active use if it is already in the
memory hierarchy. Object loading is the portion that tool implementers implementers need to look at for efficiency
considerations. Reading the data of an object, if loaded in memory, is a simple
consequence of the load initialization (vpi_load_init()) and/or vpi_load() optionally called
by the user. The API does not specify here any memory hierarchy or caching
strategy that governs the access (load or read) speed. It is left up to tool
implementation to choose the appropriate scheme. It is recommended that this
happens in a fashion invisible to the user without requiring additional routine
calls.