On Tue, Aug 5, 2008 at 9:46 PM, Nicolas Williams <nw141292 at sac.sfbay.sun.com> wrote: >
> 2. Project Summary > 2.1. Project Description: > > This project introduces a new RPC service which enables remote > read-only access to kernel statistics (kstats). The project > consists of: a RPC protocol description and header file, a RPC > daemon, and extensions to libkstat(3LIB), Kstat(3perl) and > kstat(1m) to utilize the service. I realize that the case came and was withdrawn in my absence. Nonetheless I think it useful to make some comments for the record. For background, I have written JKstat - a Java JNI interface to libkstat. One of the unfinished parts of that project is access to remote kstats. I was going to do this myself, but was interested in this proposal as it had the prospect of (a) someone else doing the work for me, and (b) it being included in Solaris by default. So I would be a potential consumer of this project. Note that the requirement is simple: access to raw kstat data. For those who argue that kstat data isn't a stable interface, then remote access (indeed any alternative access) doesn't make things any worse. And using some controlled interface (rstat, snmp) is far too restrictive. So, does this proposal meet my needs? No. One of my aims is to run a graphical interface. And then you want to run the data gathering part on the server, and the processing and heavy graphical display on a client. Where the client may not be a Solaris, or even a unix, system. And while I'm using java, I would like it to be completely platform and language independent. Using rpc is unhelpful. The rpc interfaces aren't really helpful for use from alternate languages and platforms. So, it shouldn't use rpc. Layering it under libkstat seems wrong. This restricts the primary usage target to be systems using libkstat, making porting to other platforms much harder (and those would be unsupported). So what I would expect is that libkstat would be unchanged, with a *simple* daemon layered atop. For my own project, I have been looking at JMX, which would satisfy the narrow needs I have, but wouldn't be a general solution, and I don't really like it. What I would prefer is some sort of XML-RPC service (with security provided by the transport layer). -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
