RFE: refactor mapserver to load/save map file fragments from/to strings

[sgillies@…]

I'd like to propose a change to the manner in which mapfiles
are read and written for 4.1.  My proposed changes would enable
us to write and save map file fragments.  These enhancements
are primarily aimed at improving MapServer's ability to 
serialize/marshal mapping objects.

To start, I'd like to see msLoadMap() refactored so that all
the work is performed by a msLoadMapString() function.  Then
we could reduce msLoadMap() to something like the following
pseudocode:

def msLoadMap(filename)
    fh = open(filename, 'r')
    map_string = fh.read()
    return msLoadMapString(map_string)

I'd also like to see this extended to layers, classes, etc.
msLoadMapString would call msLoadLayerString, 
msLoadClassString, etc where necessary.  These functions also
would be really handy to take an existing map and then
add a layer defined in a string like in this mapscript

layer_string = 'NAME "foo"\nTYPE POLYGON\n' # for example
layerobj = layerObj(mapobj, layer_string)

An msLoadLayerString() function would be used in this new layerObj
constructor.

As well, I'd like to see *writeString() functions for map, layer,
classes, and have msSaveMap() rewritten to call these.

Steve Lime points out that these enhancement would also be useful
for the CGI mapserv:

   In addition, this could be considered as a general
   replacement for the map_ syntax already supported by the CGI  
   application. It works well if you only need to make a change or
   two but is to clunky for much broader use. Moving to a single 
   parser that would work for a complete mapfile or just a piece 
   would really simplify maintenence.

Daniel Morissette adds:

   While we're at it, we should create an abstraction layer so that
   we can have multiple implementations of the Load...String() and
   Write...String() functions.  This way if someone wants to implement
   a XML mapfile format (did I really write XML? ;) or use whatever 
   database mechanism to store map compositions then they could do it.

This is a good idea, but I wouldn't want the issues of an XML map file
to distract from this particular feature enhancement.

While we are refactoring, perhaps we could move code into mapobject.c,
layerobject.c, etc and delete mapfile.c?

[dgraham@…]

Sean:

I hate to say this, but if there were ever a time to convert to an XML based map
file it would be tied to this refactoring.  But there would be a lot of work to
make it happen.  

Dave

[sgillies@…]

Dave, don't bring the XML map file into this :)

Seriously, I'm all for an XML map file.  Then we could
have WMS capabilities docs via XSLT and maybe even
map objects that are a DOM-like instantiation of the
map file.  But I wouldn't want to do the programming
in C or C++.  Would probably be rather grueling.

[dmorissette]

This sounded like an interesting enhancement (maybe just a bit low in the
priority list), may I ask why it's been closed as WONTFIX? Is it that the need
is gone?

[sgillies@…]

I don't have any need for this anymore.  Closed up the issue to make it easier
to focus on other bugs.

[sdlime]

Re-opening though, cause other folks do need it. It's not a high priority and I 
doubt I could forget about this feature but it's already here...

[sgillies@…]

Would it be possible to remove me as reporter?  I closed it so I wouldn't
have to see this thing in my list of active bugs ... where it's been with no
action in 14 months.

[sdlime]

I'll refile the bug and close this one...

Steve

[sgillies@…]

Am trying to shorten up my list of active bugs.  Marking this resolved will 
really help me out.  It can always be found in the database if anyone needs to 
refer to it.