[Geoserver-devel] Configuration File Vote

GeoServer GeoServer Developer
1

As some of may be aware I have been looking into forming a set of hooks into the configuration system for a client interface. At this time I have to consider whether to create yet another configuration format.

If the new format were adopted, most of the work would be completed by the Betwixt project from Jakarta if we use a new format. We would still need to create and maintain code for reading the existing XML format, but this would have to be created either way.

Thank-you

David

NOTE: Betwixt uses Digester to read XML, but does not support generic bean XML writing.

2

As some of may be aware I have been looking into forming a set of hooks
into the configuration system for a client interface. At this time I
have to consider whether to create yet another configuration format.

If the new format were adopted, most of the work would be completed by
the Betwixt project from Jakarta if we use a new format. We would still
need to create and maintain code for reading the existing XML format,
but this would have to be created either way.

So my main concern, expressed in IRC, is that we don't want GeoServer to
be a project constantly switching configuration formats around. I am a
bit hesitant about putting in more layers from third parties, as it often
adds more constraints. We originally did configuration with Castor, but
it made it very difficult to add new configuration fields, since the
classes had to be rewritten, and it meant that any old config files that
were missing _all_ config fields would choke. So we changed over to just
reading with DOM, which gave us complete control over how we dealt with
the code. The nice thing about that change was that from a user
perspective absolutely nothing changed.

The nice thing about the memory model is that different formats just need
a custom reader to transform it.

So I guess my requirements for a new format are about as follows:

1. Human readable _and_ writable. So that admin type people who are
more comfortable working with xml files than with gui config tools can
easily configure. I would also like it so that comments persist, in at
least some form - the current config files have comments for all the
fields, so that you do not have to reference other files just to know
LoggingLevel is and the appropriate values. I personally hate it when you
use an automatic tool that just butchers everything into the exact way it
wants it. I know that this request may be a bit ridiculous, and therefor
it's not required, but I would definitely like it so users can just bypass
the gui config, and not have it somehow destroy all their comments and
whatnot.

2. Flexible, easy to add new config fields to. THis was the problem with
the castor stuff, adding a new field broke all the old config files. I
know that things are probably going to have to change for the first big
shift, but after that we will have new additions, and I want to be sure
that someone with GeoServer 1.2.1 who upgrades to 1.3.3 doesn't have to
change thier config files around. That new fields will come up with
reasonable defaults.

3. In xml, which betwixt is, but I'd just like to point out that we want
it so we can easily revert to pure DOM tools if the third party libraries
get outdated or can't meet all our needs.

4. Support for old data formats. This doesn't _need_ to be seamless
(though it would be nice), but at the very least we should provide
converter tools for older users to get their stuff up to date.

5. Compatible with gui and memory model (though this is obviously already
the main design goal).

So those are my thoughts. I'll try to look more at betwixt to see if
anything jumps out at me as bad. If anyone has any good or bad
experiences with betwixt please let the list know.

thanks,

Chris

Thank-you

David

NOTE: Betwixt uses Digester to read XML, but does not support generic
bean XML writing.

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--

3

Interesting - what did you guys decide to do? Keeping comments around is *really* tough since we are planning on up rooting the DOM tree and cutting it into bean sized boxes.

Jody
Chris Holmes wrote:

As some of may be aware I have been looking into forming a set of hooks into the configuration system for a client interface. At this time I have to consider whether to create yet another configuration format.

If the new format were adopted, most of the work would be completed by the Betwixt project from Jakarta if we use a new format. We would still need to create and maintain code for reading the existing XML format, but this would have to be created either way.
   
So my main concern, expressed in IRC, is that we don't want GeoServer to be a project constantly switching configuration formats around. I am a bit hesitant about putting in more layers from third parties, as it often adds more constraints. We originally did configuration with Castor, but it made it very difficult to add new configuration fields, since the classes had to be rewritten, and it meant that any old config files that were missing _all_ config fields would choke. So we changed over to just reading with DOM, which gave us complete control over how we dealt with the code. The nice thing about that change was that from a user perspective absolutely nothing changed.

The nice thing about the memory model is that different formats just need a custom reader to transform it.

So I guess my requirements for a new format are about as follows:

1. Human readable _and_ writable. So that admin type people who are more comfortable working with xml files than with gui config tools can easily configure. I would also like it so that comments persist, in at least some form - the current config files have comments for all the fields, so that you do not have to reference other files just to know LoggingLevel is and the appropriate values. I personally hate it when you use an automatic tool that just butchers everything into the exact way it wants it. I know that this request may be a bit ridiculous, and therefor it's not required, but I would definitely like it so users can just bypass the gui config, and not have it somehow destroy all their comments and whatnot.

2. Flexible, easy to add new config fields to. THis was the problem with the castor stuff, adding a new field broke all the old config files. I know that things are probably going to have to change for the first big shift, but after that we will have new additions, and I want to be sure that someone with GeoServer 1.2.1 who upgrades to 1.3.3 doesn't have to change thier config files around. That new fields will come up with reasonable defaults.

3. In xml, which betwixt is, but I'd just like to point out that we want it so we can easily revert to pure DOM tools if the third party libraries get outdated or can't meet all our needs.

4. Support for old data formats. This doesn't _need_ to be seamless (though it would be nice), but at the very least we should provide converter tools for older users to get their stuff up to date.

5. Compatible with gui and memory model (though this is obviously already the main design goal).

So those are my thoughts. I'll try to look more at betwixt to see if anything jumps out at me as bad. If anyone has any good or bad experiences with betwixt please let the list know.

thanks,

Chris

4

Chris and I agreed on this solution, sorry forgot to include the list.

"I'll keep it the same as before, almost as easy to code. The only problem will be user comments will be lost when writing to the files. I can insert directive default comments, but any personalized ones would be lost (otherwise the dom needs to reside in memory, which is neither efficient nor practical for any scaleable system with ~100 featuretypes for example). I should also note, XML writing ONLY occurs when the GUI configuration manager is used, so those who wish to avoid it can do so without risking their personalized comments. "

David

Jody Garnett wrote:

Interesting - what did you guys decide to do? Keeping comments around is *really* tough since we are planning on up rooting the DOM tree and cutting it into bean sized boxes.

Jody
Chris Holmes wrote:

As some of may be aware I have been looking into forming a set of hooks into the configuration system for a client interface. At this time I have to consider whether to create yet another configuration format.

If the new format were adopted, most of the work would be completed by the Betwixt project from Jakarta if we use a new format. We would still need to create and maintain code for reading the existing XML format, but this would have to be created either way.
  
So my main concern, expressed in IRC, is that we don't want GeoServer to be a project constantly switching configuration formats around. I am a bit hesitant about putting in more layers from third parties, as it often adds more constraints. We originally did configuration with Castor, but it made it very difficult to add new configuration fields, since the classes had to be rewritten, and it meant that any old config files that were missing _all_ config fields would choke. So we changed over to just reading with DOM, which gave us complete control over how we dealt with the code. The nice thing about that change was that from a user perspective absolutely nothing changed. The nice thing about the memory model is that different formats just need a custom reader to transform it. So I guess my requirements for a new format are about as follows:

1. Human readable _and_ writable. So that admin type people who are more comfortable working with xml files than with gui config tools can easily configure. I would also like it so that comments persist, in at least some form - the current config files have comments for all the fields, so that you do not have to reference other files just to know LoggingLevel is and the appropriate values. I personally hate it when you use an automatic tool that just butchers everything into the exact way it wants it. I know that this request may be a bit ridiculous, and therefor it's not required, but I would definitely like it so users can just bypass the gui config, and not have it somehow destroy all their comments and whatnot.

2. Flexible, easy to add new config fields to. THis was the problem with the castor stuff, adding a new field broke all the old config files. I know that things are probably going to have to change for the first big shift, but after that we will have new additions, and I want to be sure that someone with GeoServer 1.2.1 who upgrades to 1.3.3 doesn't have to change thier config files around. That new fields will come up with reasonable defaults.

3. In xml, which betwixt is, but I'd just like to point out that we want it so we can easily revert to pure DOM tools if the third party libraries get outdated or can't meet all our needs.

4. Support for old data formats. This doesn't _need_ to be seamless (though it would be nice), but at the very least we should provide converter tools for older users to get their stuff up to date. 5. Compatible with gui and memory model (though this is obviously already the main design goal).

So those are my thoughts. I'll try to look more at betwixt to see if anything jumps out at me as bad. If anyone has any good or bad experiences with betwixt please let the list know.

thanks,

Chris