[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: proplib and the jet age
On Fri, Jan 04, 2013 at 08:50:35PM -0600, David Young wrote:
> > It seems to me that the basic complaints, reflecting real problems,
> > are the following:
> > (1) It was never clear whether proplib is supposed to be a data
> > *transfer* API (that is, data lives in application data structures and
> > gets loaded into and out of proplib only for shipment) or a data
> > *storage* API (that is, data lives in proplib and applications use
> > proplib to access it). As a result of this proplib has aspects of both
> > these things and is a good solution for neither.
> According to this definition, I have to come to think of it as a
> data transfer API of a very narrow type: essentially it is one for
> transferring in one "bundle" several datums of the sort that sysctl(3)
> moves between the user and kernel.
Yes, this is exactly what I've been trying to express.
> Now, what to call that? A MIB?
Good question... perhaps so.
> Anyway, I've come to think of sysctl and proplib as both unnecessarily
> hard to use *and* redundant with each other.
Sort of. They don't fully overlap; given a bundle as described above,
the sysctl(3) API is something like a query interface for it. But not
a very good one. Nor is the numerical and hierarchical MIB structure a
good data model.
There are a number of *ctl(8) utilities that do things similar in
appearance to sysctl(8); many of them have their own custom backends.
Cleaning all this stuff up to share one common representation and
addressing model has long been a goal. It might be possible to
actually do that using a proplib replacement.
There's a further complication, namely that a number of things
retrieved with sysctl(3) need to be retrieved reasonably fast...
David A. Holland
Main Index |
Thread Index |