Persistency on contexts

[Frank Fock]

helge.fredriksen____4tel.no wrote:

> I was hoping that things got stored persistently when performing these
> calls, and restored with mib->init(), but it doesn't seem so.
>

They are not stored at the moment you call addContext or
addNewAccessEntry. They are stored when the desctructor
of the Mib instance is called. But you may call Mib::save_all()
to store persistent MIB objects subsequently.

>
> Now, I have noticed that there is a context handler class called MibContext,
> and that there exist methods like add_context and delete_context in the Mib.
> Also there is some info on persistency on the MibContext class in the
> documentation. How does the vacm contexts differ from the Mib contexts?
>

It is the same context. The Mib context holds the MIB information and the
corresponding VACM context the access information for that MIB information.

Both "contexts" are not synchronized with each other, however the API
user should always add a VACM context when adding a Mib context
with the same name.

>
> Thus I wonder if I should rather start using these facilities to make my
> contexts persistent? Today we use a workaround to avoid multiple MibContexts
> (a previous recommendation of yours).
>

Currently, the Mib contexts are not stored at all. I will add this
feature for the next release. At moment you will have to use the VACM
MIB, to restore your context names.

>
> Could you please give me some clues? Any demos on the use of the MibContext
> class?
>

The ATM example that comes with AGENT++v3.4 is a
simple demo.

Regards,
Frank