Frank> Good point. Currently, there is no libsmi function that allows Frank> you to retrieve the instance part of a given OID or Frank> string.
Juergen> The question is whether libsmi should go into the direction of Juergen> providing a library of utility functions that are commonly needed by Juergen> applications that use libsmi.
Well, in this case the lack of such a function is pretty fundamental. I need to be able to split a full OID into "object" and "instance" parts (which I don't think is an unreasonable thing to want to do :-) )
At the moment, I can use libSMI to parse an object string "TCP-MIB::tcpConnTable.1.1.0.0.0.0.21.0.0.0.0.0"
and be told "Here's the node that you asked about (tcpConnState). Oh - and there was some junk on the end, but you probably don't want to know about that."
But I *dooooo* !
I can't simply extract the last numeric subidentifier from the string manually, since the instance part is longer than that. I can't search for the first numeric subidentifier either, since the first two such subidentifiers are actually included within the node that smiGetNode() has returned.
I've either got to duplicate the OID parsing within my application (which rather defeats the point of using the library in the first place).
Or else I've got to work through successive substrings (either building up from "TCP-MIB::tcpConnTable" or knocking elements off the original string) until I find the point at which libSMI starts giving me a different result. That would tell me where the object/instance divide comes - but feels a somewhat cumbersome approach.
Frank already knows this information anyway - why won't he tell me. S'not fair!
Frank> Another example I could imagine is the formatting of Frank> a value according to an object's/type's display hint.
I think that's a slightly different situation. Yet it would be useful to have this handled within the library - but as long as the library provides the raw material (the basic value, and the hint string), I can at least do this myself.
The object/instance division is different - the basic information just isn't available in the first place.
Juergem> I think it all boils down to: Who is going to work out the API and Juergen> implement, document and test this stuff? Volunteers?
Well, I need this functionality pretty badly - without it, I can't see how we can sensibly adopt libSMI for the net-snmp suite. So I'm quite happy to do much of the donkey work. But I'm coming new to this package, so I'm not really au fait with the general design philosophy here. It's probably not sensible for me to suggest an appropriate API in keeping with the rest of the library. (And of course, the rest of you will be more familiar with the code than I am - so I'm probably not the best choice of coder either. But I'm quite happy to do this, if I'm given a basic design to work from).
Dave
-- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to libsmi-request@ibr.cs.tu-bs.de. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.