Persistency question...

[Cuong Nguyen]

Hi folks,

I just started looking over agent++ and have a few questions regarding
persistency and other things.  I did read through the documentation and
looked over the example codes before posting this message.  I'm new to this
code so if I'm say something that is completely
wrong please correct my assumption as appropriate.

1 - it seems that an entire MIB table is made persistent at a time.  For
example the atmMib
    example shows that an entire VPL table is stored and retrieved at once
during
    construction and destruction.  Now when a table consists of a very large
number of
    entries this could be a very time consuming and inefficient step.  For
example, in
    practical use an ATM VPL table could consists of tens of thousands of
entries (or
    more).  Are there other alternatives for this such as storing the
entries in indexed
    file and retrieving a row at a time instead of an entire table?  What I
would like to
    do is not retrieve the row until it is actually accessed because of a
request rather
    than at the time of construction.  I guess I can do this using the
mechanism described
    in my second question below.

2 - Similar to the question 1, I have question for get_next.  Currently it
looks like the
    "get_next" processing is handled completely by the agent++ toolkit.
This makes sense
    again for smaller agent implementation but for large tables such as ATM
VPL, this would
    be problematic since the agent expects to know about all the entries in
the table (all
    entries must be added specifically).  Currently, when a get_next is
requested, the
    Mib::find routine is executed which searches the "content" list which is
a list of all
    existing rows (again it looks like all rows must have been previously
added to the
    agent).  What I would like to be able to do is to have virtual rows that
does not
    have to be added to the MIB until it is requested by someone.  So when
get_next is
    called I would like to have an opportunity to add the row at that time.
I guess I can
    do this myself by overloading the "get_next" routine for a given table.
Then, I can
    look in my own cache to see if the object exists then check to see if it
is in the
    "content" list already or not.  If not I can add it to the content list.
I guess I
    would also like to remove the entry from cache at some point (when?).  I
would refresh
    my cache from persistent storage if the cache object does not exist.  If
the object
    is not in persistent storage either then I would not add to the
"content" list which
    would result in a "no-such-name" error from get_next.  It would be nice
if this behavior 
    is modeled in the library so I don't end up just hacking it :-).

3 - another similar issue is when a MIB table and all rows are derived
dynamically or maybe
    is a model of a database or log file.  In this case it is not efficient
to load the
    entire log file or database in at the time of construction.  It would be
better if only
    the required row is retrieved at the time of request.  In this case the
agent library
    might want to provide a method by which the agent call the "table" (not
entry) object
    to retrieve the row in question at the point of request.  This means
that the agent
    does not know at all whether the row is present and must leave the
determination to
    runtime code.  The agent library may also need help from runtime code to
determine if
    a column exists.  To do get_next in this case the agent library will
also have to
    delay the determination of the next valid "row" in a table to runtime
code.

Again, I'm new to this code so if I'm totally off in my understanding of the
code please
forgive me.  Thank you for your time.

Cuong.