> When building an ESM, you have some fairly complex challenges. At the > top > of the list, the ESM > 1. Cannot be simply or easily circumvented (even by a sysadmin [as > opposed > to sysprog] ), > 2. Must enforce a limited set of operations when the ESM server is down > sufficient only to get the ESM server back up and running or to declare > "The ESM's dead, Jim." > 3. Must recognize and differentiate system initialization activities > from > 'steady state' stuff > 4. Must generally support the idea the CP is the enforcement point. > Policy > may be derived from a server, but CP is where the Real Decisions are > made > and where it is understood that, sometimes, the policy does not apply > or > is a Really Bad Idea in some cases. > > That's impossible to do if all the logic is in the server.
Something tells me we're actually agreeing with each other but using different words. I'm not arguing against any of those points. I am arguing that the current implementation makes implementing code (both for the programmer and the user) that exploits the existing interfaces unnecessarily complex (and release dependent), thus increasing everybody's cost of operation and ownership. I'm arguing that we don't have to reinvent that consolidation piece to present a way to connect a ESM to CP. But, never mind. Just an idea. If somebody wants it, they'll holler. -- db
