Wiki code for Visual Panels

Hide Line numbers
1: == Visual Panels ==
2: 
3: === Introduction
4: 
5: We often receive feedback that Solaris is too difficult to configure.
6: Specifically, things which are easy to configure on other operating
7: systems can sometime involve a complex set of error-prone steps on
8: Solaris.  There are many reasons for this:
9: 
10: * We might force the user to manually express their high-level intent
11:   as a (usually large) set of low-level configuration changes.
12: * If there is a tool which allows the user to easily express high-level
13:   configuration changes, it isn’t always well publicized or easy to find.
14: * If the tools are known, users may be forced to go to different places for different configuration tasks.  The individual tools may look different or behave in different ways.
15: 
16: All of these are serious problems.  A user trying to make a basic
17: configuration change should be able to go to one place and find a
18: simple, intuitive tool which behaves consistently with the tools they
19: use for other configuration tasks (if using separate tools is, in
20: fact, necessary).
21: 
22: Mere parity with other operating systems isn’t the only goal, though.
23: There are many features unique to Solaris which theoretically allow
24: us to do a more complete job.  For example, SMF gives us a much
25: better view of how the different pieces of system software are
26: interelated, and together with FMA it allows us to better understand
27: and communicate software or hardware failures.
28: 
29: 
30: === What we want Visual Panels to do
31: 
32: We want to provide a single, unified place for an end user to access
33: those things he wants to configure on an OpenSolaris system.  This
34: includes desktop settings, hardware settings, system settings, etc.
35: That said, solutions which involve enormous start-up times and put the
36: user at serious risk of getting lost within the configuration tool
37: itself don’t count.
38: 
39: The user experience should be tailored to what we offer in
40: OpenSolaris.  This doesn’t mean including the ability to tweak every
41: Solaris-specific knob, but rather including those things which are
42: uniquely useful or simply integral to the Solaris experience.  The
43: ability to provide diagnoses when requested configuration actions fail
44: due to causes other than the administrator’s immediate actions, for
45: example, should be ubiquitously available.
46: 
47: The user experience when modifying a particular aspect of the system’s
48: configuration should be consistent as possible across different
49: environments.  This refers both to configuring remote machines (which,
50: because of their similarity, we will also use to refer to Zones), as
51: well as to configuring a Solaris machine from a non-JDS environment.
52: "non-JDS" environments include:
53: 
54: * OpenSolaris systems running an evolved future version of JDS (i.e. a
55:   natural progression from where we are)
56: * OpenSolaris systems running a successor to JDS (i.e. a more radical
57:   progression)
58: * OpenSolaris systems running an alternative windowing system (e.g.
59:   KDE, twm)
60: * Non-OpenSolaris systems
61: * Web browsers
62: * TTYs
63: 
64: (We are not proposing providing specific solutions for all of these,
65: but would consider producing something which would require duplicating
66: common functionality to add support for one of these environments
67: failure.)
68: 
69: We should be creating and using reusable components.  If we need to
70: create a better set of interfaces for accessing some part of the
71: system, we should publish those so that others with the same needs can
72: benefit.
73: 
74: 
75: === Where we are right now
76: 
77: As was mentioned earlier, SMF offers us a lot.  Instead of ad-hoc
78: startup scripts, we have well-defined services with dependencies.
79: Moreover, instead of continuing to force administrators and ISVs to
80: create armies of simple but subtly different configuration files (or
81: worse yet, condone the use of non-interfaces like modifying rc.d
82: scripts), we created a convenient place to store basic typed
83: configuration.  In short, it has removed a lot of unnecessary
84: heterogeneity.
85: 
86: Because of this, we decided that SMF was a good foundation to build
87: upon.  Doing so meant we could automatically handle any service
88: currently in SMF, and without modification handle new services
89: delivered in future releases of Solaris or by ISVs.  Additionally, we
90: could make incremental enhancements to the data stored in SMF that
91: would allow service authors to instantly gain improved functionality
92: for a relatively minor cost.  Lastly, we could provide a means for
93: service authors to deliver a custom interface for their service.  This
94: would be particularly useful in those cases where the underlying
95: configuration was more complicated than a user should be forced to deal
96: with, or when the configuration wasn’t published via SMF.
97: 
98: We also decided that Java was a good language for implementation.
99: Though the language itself is more complicated than something like C,
100: the development process is far simpler.  It also has a well-integrated,
101: stable set of APIs for GUI development.  The Java platform also
102: includes mature APIs for remote management, XML parsing, data
103: structures, and other things which would normally require us to manage
104: a slew of other libraries (and their versions).  Last but not least,
105: it’s portable, which makes it much easier to allow configuration of
106: Solaris machines from non-Solaris platforms.
107: 
108: Without getting into any more narrative, we have assembled the
109: following software components:
110: 
111: ==== Java SCF interfaces
112: 
113: At the bottom of our software stack is a set of Java interfaces for the
114: SCF (Service Configuration Facility - the technology just beneath SMF)
115: and SMF.  These interfaces allow both reading from and writing to the
116: SMF repository from Java programs.  We hope to publish a future version
117: of these interfaces and integrate them with Solaris so that others can
118: take advantage of them.
119: 
120: [[More about the Java SCF interfaces>>javascf]]
121: 
122: ==== The JMX Agent
123: 
124: The next piece is a [[Java Management Extensions (JMX)>>http://java.sun.com/jmx]]
125: Agent which
126: publishes MBeans for SMF services on a Solaris system.  Inserting an MBean
127: layer between our configuration tool and the system not only
128: facilitates remote management, but should also provide interoperability
129: with third-party management frameworks which consume MBeans.
130: 
131: [[More about the JMX Agent>>jmxagent]]
132: 
133: ==== The Visual Panels demo application
134: 
135: Lastly, we have a simple application, {{code}}vp{{/code}}, which helps us exercise the
136: underlying interfaces and serves as a testbed for our ideas.  Many of
137: the above principles are reflected in {{code}}vp{{/code}}, though {{code}}vp{{/code}} as a whole doesn’t
138: represent what we think a configuration tool should look like.
139: 
140: [[More about the Visual Panels demo>>vpdemo]]
141:
OpenSolaris

Top Menu

Wiki code for Visual Panels

Search

Collectives

Community Group

Project

User Group

Subsites

Project vpanels Pages
