[Mapserver-dev] CONFIG Keyword

[Sean Gillies]

On Mar 15, 2004, at 1:23 AM, Frank Warmerdam wrote:

> 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,

Frank,

Now that I better understand what you are doing, maybe my suggestion 
wasn't
so smart.  A hash table is basically just an array of strings, a place 
for
storing values, right?  Your configoptions is different because 
msSetConfigOption
has other effects than just storing a value in the hash.

Thanks for updating msCopyMap and alerting me to the leaks.

Sean