[Mapserver-dev] CONFIG Keyword

[Frank Warmerdam]

Sean Gillies wrote:
> I have a suggestion: to use, perhaps, MapServer's hashTableObj  
> structure for
> the config instead of a pair of string arrays?  One of these days I am  
> going
> to figure out how we can expose MapServer's hashes to SWIG and then we  
> will
> be able to drop the setOption/getOption methods in favor of
> 
>    mapobj.config['foo'] = 'bar'
>    layerobj.metadata['wms_title'] = 'wms layer'
> 
> Could you also update the msCopyMap function in mapcopy.c so that it  
> properly
> replicates your new mapObj structure members?

Sean,

I have rewritten the CONFIG support to use a hashTableObj as suggested.
I looked around in map.h for a property list data structure or something
similar but never noticed the hash table stuff in maphash.h.

I have taken the liberty of changing a few of the hash functions to use
const char * where appropriate though I found it introduced too much hassle
to have msLookupHashTable() return a const char *.

I also had to add interator functions for the hash table object so it
is possible to opaquely get a list of all values in the hash table.
These are msFirstKeyFromHashTable() and msNextKeyFromHashTable().

Finally, I took the liberty of modifying the default hash table size to
41 from 40.  I was taught that it is bad hash-table-mojo to use hash table
sizes that are too "factorable", and that prime sizes are best.

As suggested, I updated mapcopy.c to copy the config options, and I modifed
msSaveMap() to actually save them ... something I forgot before.  I was able
to test all this out quite easily from mapscript.

I would add that it would be unwise (as things stand) to directly expose
the configoptions hashTableObj in mapscript even if we have nice bindings
for it as you suggest.  Some config options are immediately applied
as soon as they are set as they may affect handling of later operations in
parsing.  Currently only PROJ_LIB falls into this category as it is potentially
needed when parsing PROJECTION objects as they are immediately converted into a
PROJ.4 object.  In short, msSetConfigOption() may actually take immediate
actions for some config options, so we want to ensure that all config option
setting goes through that function.

PS. I also took the liberty of doing a bit of warning cleanup in various places
while trying to verify my changes.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent