> I don't personally really like save or backup type things unless there is > binary details unavailable from a simple dump/restore-from-dump. I guess > what I'm saying is that "save" should be dropped from mention. The "set" > should _all_ work immediately (caveat when necessary). And "show config", > like now should dump the entire config out for saving to a file somewhere.
I OTOH like a commit-like interface, where a set of changes is prepared but then executed atomically. It'd be nice to have both ways, via some "autocommit" switch in the shell (which would implicitly save/commit after each command is validated) >> I have an idea to use snmp to get statistic information and http to >> change/put/get existing info > > SNMP is read-only at present due to the library we use. We need a major > library change at some point to do updates or bulk transfers properly, but > out of scope for a shell project. A problem lies in _finding_ such a library.. there are a few out there, but most of them seem abandoned.. > Kinkie, is working on merging cachemgr reports and SNMP reports. So you > should not need to worry about SNMP even for reads. It will all be provided > via the same cachemgr actions internally. Yes. My wish would be to enable reporting SNMP and CacheMgr using the same internal interfaces. > So far all actions are at the global scope. But since components might be > disabled or simply missing from the build I think we need to consider > something like BusyBox shell does. With a "use" command to move 'into' a > component scope and the get/set/show commands become limited or expanded to > ones available only in that component. I find JunOS' cli interface extremely powerful. > I'm hoping we can add this scoping to the cachemgr web interface as well via > a menu system. Still thinking through the consequences and design there > though. The actions would be using the '/' path syntax of URLs for that. ie > action "icap/config" to just show the icap specific configuration object > dump. +1 -- /kinkie
