RE: [Mibble-users] mibble suggestions

[Zemian Deng]

Thanks on the reply Per,
You're welcome on the suggestions.

On the last point, what I meant on caching is to cache a parsed mib file
instance so that you don't need to re-parse the same mib again; even when
you re instanciating another new MibLoader. Perhaps make the MibLoader class
serializable? There is no reason to reparse std ietf mib files again and
again. Of course allowing deleting the cached should reparse it again. Does
this make sense?
--zemian

PS. This issue come up when everytime I run a script to parse a device mib,
the time to load the std ietf mib is 10 times longer than just the device
mib.

-----Original Message-----
From: address@hidden
[mailto:address@hidden Behalf
Of Per Cederberg
Sent: Sunday, December 07, 2003 4:17 PM
To: address@hidden
Subject: Re: [Mibble-users] mibble suggestions


Forgot to cc: my answer to the list.

/Per

-----Forwarded Message-----
From: Per Cederberg <address@hidden>
To: Zemian Deng <address@hidden>
Subject: Re: [Mibble-users] mibble suggestions
Date: Mon, 08 Dec 2003 00:06:41 +0100

On Mon, 2003-12-08 at 00:42, Zemian Deng wrote:
> Hi,
> I have tried mibble2.1 and it works well. I do have few suggestions that
> maybe you could look it.

Hi Zemian,

Suggestions are always very welcome!

> 1. The loaded mib's name seem to take the file name intead of the name
> defined inside the mib. Therefore if the file name different than the
> defined mib name, it will failed the import by other mib file.

Ok, I admit to not having given this much thought.
Problem is that to know the "correct" MIB name one
must parse the MIB file (or at least part of it).

So, in order to find imports easily and quickly
Mibble currently assumes that files will be named
"<mibname>[.<extension>]". As a workaround I
recommend you change your MIB file names to match
this standard, especially as it seems to be
commonly used almost everywhere.

In a future version of Mibble I'll look into if it
isn't possible to take the actual MIB name from
inside the MIB file into consideration. Only so
that if you've already loaded the MIB file,
subsequent imports using that name will find that
is has already been loaded. Doing it any other way
would risk bringing performance to a crawl...

Sorry that I can't give you a bug # for this, but
it seems Gnu Savannah is still down.

> 2. The MibLoaderLog didn't provide iterator to loop through errors. I can
> only print them all at once or nothing right now.

This issue was fixed in Mibble 2.2 that was released
some time ago. Please check it out, as it contains
some other improvements and fixes as well.

> 3. Feature for Cached or saving the loaded mib will greatly improve app's
> performce. (Specially when writing a script for it. I am using jython to
> access your api, and they work well.)

Cool to hear that Mibble works with Jython. If you
find anything that might make integration with
Jython easier, I'd be interested in fixing it.

Regarding caching I'm not sure I understand
completely. Any loaded MIB file remains in the
MibLoader for as long as you keep it around. If you
load several MIB:s through the same MibLoader instance,
no reloads will happen (i.e. it works like a MIB cache).
Is this what you meant? Or where you referring to
something more advanced?

Many thanks for your time and suggestions, Zemian!

Cheers,

/Per



_______________________________________________
Mibble-users mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/mibble-users