Re: [higgins-dev] Discovering configurable elements and their structuref

[Greg Byrd <gbyrd@xxxxxxxx>]

Here's what I'm thinking about how to describe a configuration.

(1) Create a class called SettingDescriptor that holds parameters about a setting:  name, type, display string, doc string, constraints.  The class will either be general enough to describe map, list, and simple setting types, or we can specialize the class.  A map descriptor will contain descriptors for its subsettings, etc.

(2) Add a getConfigurationSchema() method to IConfigurableComponent.  It returns a SettingDescriptor.  The descriptor can be built by reading a configuration file (as Daniel suggests), or just be having a static method of the class (or some descriptor class) that knows how to create it. 

(3) We can invent a declarative way to describe a configuration schema, and a helper class that knows how to convert it into a SettingDescriptor, if that seems more maintainable/user friendly than specifying it in code.  The schema string could be kept in a file, or in a static string variable, etc.  This is totally up to the class that is responsible for creating the SettingDescriptor.

I think it would be better to have a standard class that represents the schema, rather than than having the format hardcoded into a management application.

...Greg



Daniel Sanders wrote:

Someone might be tempted to suggest XML Schema.  However, I think that approach would be clumsy and burdensome at best.  There is an XML Schema that describes legal use of <Setting> elements to create configuration documents, but it is limited to describing configuration documents in a very general sense.  It does not describe what constitutes valid combinations of <Setting> elements for specific kinds of configuration (e.g., JNDI configuration, STS configuration, etc.).  Although I could envision XML Schemas that did describe specific valid configuration schemas, I think it would be extremely ugly.

 

I would propose that we describe the schema of a particular kind of configuration using another "schema configuration."  Such a "schema configuration" is simply a special kind of configuration whose legal structure and constraints are well understood by the management utility.  In other words, the schema configuration would itself have a well-known schema.  Obviously, it could be used to describe its own schema (just as XML Schema can be used to describe the proper syntax for XML Schema).  However, other than perhaps for documentation, there is no practical need for it to describe itself.  The knowledge of the schema of a "schema configuration" has to be hardcoded in whatever application needs it (such as management utilities) in order for it to be put to practical use.  (XML Schema parsers do not rely on the XML schema that describes XML schema to parse an XML schema.  The knowledge of XML schema is hardcoded in them.)

 

The advantage of this approach is that we already have libraries for accessing configuration objects, so the management utility doesn't have to use a separate set of libraries to access and process a configuration schema.  It can use configuration objects to both understand a configuration schema and then create a valid instance of the configuration schema.

 

Daniel

>>> "Tom Doman" <TDoman@xxxxxxxxxx> 7/16/2007 9:54 AM >>>
While we have to document every available setting and how to structure it for all our configurable components, we also need a way for management utilities to dynamically provide an interface to allow configuration of each setting.  In other words, we need another schema to describe this stuff and I was pondering whether we could reuse concepts and code we've already created here or whether we'd end up with "chicken and egg" problems.  I also don't know how what Markus is doing might play into this as well as we modify XRDS documents with our configuration data inside.

Does anyone else have any thoughts or comments on this issue?

Thanks,
Tom


_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev