Re: [Fwd: [scli] scli moving to glib-2.0 and modularization]
I also played some time with the idea to separate out the SNMP implementation. I did just that yesterday by creating a package tentatively called gsnmp. The idea here would be that others can reuse the glib-based SNMP library easily. Now, making this split would imply that scli has another dependency. If you think this is a problem, please let me know.
There is another open question: Should the scli stubs also become a reusable separate package? It would make sense if there are people who are interested to develop other applications that make use of the stubs. One could package this as gsnmpietf (stubs for the IETF MIBs), gsnmpnortel, gsnmpcisco, ...
From my point of view (short intro: Michael Goffioul, KDEPrint and
sKli developer), having access to separate libraries to perform all the SNMP dirty work is a plus. Having access to the internal data is much faster and more reliable than parsing the scli standard output (whose format can change from one version to the other). So I'm pretty much in favor of such a development direction. For the dependency problem, you can still package the whole source code into one package, containing the various libraries and the scli executable, and leave the splitting into separate binary packages to the distro packagers. As final note, I'll add that having access to the stubs is (at least for me) as important as for the gsnmp alone. So yes, putting stubs accessible in separate package/libs is pretty useful.
Bye. Michael.
Michael Goffioul writes:
Michael> From my point of view (short intro: Michael Goffioul, Michael> KDEPrint and sKli developer), having access to separate Michael> libraries to perform all the SNMP dirty work is a Michael> plus. Having access to the internal data is much faster and Michael> more reliable than parsing the scli standard output (whose Michael> format can change from one version to the other). So I'm Michael> pretty much in favor of such a development direction. For Michael> the dependency problem, you can still package the whole Michael> source code into one package, containing the various Michael> libraries and the scli executable, and leave the splitting Michael> into separate binary packages to the distro packagers. As Michael> final note, I'll add that having access to the stubs is (at Michael> least for me) as important as for the gsnmp alone. So yes, Michael> putting stubs accessible in separate package/libs is pretty Michael> useful.
I just tried to create a stub library which contains stubs for all IETF MIB modules. The downside of this approach is that the resulting stub library is rather big (4M). The upside is that there is one library with everything included - so all the stubs are readily available. There might be other ways to split things in more reasonable sized pieces. (Or if there someone who can tell me how I can generate more space efficient stubs, I would love to do so.)
Generate and compiling gsnmp/scli stubs for all IETF modules also showed some bugs in the stub code generator. (Yeah, some IETF MIB modules use descriptors that are reserved words in C. ;-) But in general, I tend to like the setup with three source packages - one for the gsnmp library, one for the stubs and one for scli. But getting all the packaging stuff right might take some more time...
/js
I just tried to create a stub library which contains stubs for all IETF MIB modules. The downside of this approach is that the resulting stub library is rather big (4M). The upside is that there is one library with everything included - so all the stubs are readily available. There might be other ways to split things in more reasonable sized pieces. (Or if there someone who can tell me how I can generate more space efficient stubs, I would love to do so.)
The stubs contains a lot of static data, I don't think you'll be able to reduce the library size significantly. For your information, the final scli executable (which contains everything) has a size of 2.5 MB, compiled with gcc-3.1, on my system. Anyway, the stub library size is not really a problem, as it can be shared by many executable whose size should be rather small.
Michael.
Michael Goffioul writes:
Michael> The stubs contains a lot of static data, I don't think you'll Michael> be able to reduce the library size significantly.
I do not know the details of the ELF format, but something tells me that the stubs should be smaller. The actual amount of data and machine instructions is not really that big.
Michael> Anyway, the stub library size is not really a problem, as it Michael> can be shared by many executable whose size should be rather Michael> small.
Yes, the size is not critical.
/js
participants (2)
-
Juergen Schoenwaelder -
Michael Goffioul