RFC 31: Loading MapServer Objects from Strings
Steve Lime
Steve.Lime at DNR.STATE.MN.US
Tue Jun 19 22:52:21 EDT 2007
1. Yes, this alters current behavior (restores pre-4.10 behavior though) by
simply overriding.
2. No, I'm not talking about calling freeObject. I'm thinking finer grained. For
example, if a mapfile sets TEXT 'this is the original text' and the string-based
update sets TEXT 'this is an updated text value' then we need to make sure
we free the memory initially allocated prior to overriding. The current URL
setting code does this. Just need an msFree ahead of string setting.
msFree(class->text);
class->text = strdup(msyytext);
3. This statement was intended to allow for ease of use by folks. When parsing
a file the object identifier (e.g. LAYER) is stripped off with the parent object. For
example, a CLASS is recognized by loadLayer so that token never is encountered
by loadClass. I think it makes much more sense to send string to configure a
classObj with the CLASS keyword even though it doesn't mean anything.
You are correct though, the last definition wins but only for the parameters it sets.
Those it doesn't touch are left as is. That's why I thought a "clear" method might
make sense some sense so folks could start from scratch.
4. Serialization to strings, we could change all the "objectWrite" functions to write
to a string and then change msSaveMap to just output that string to a file. Those
functions would serve as "asString" methods for each object in MapScript. That
wouldn't be too hard a change if someone has a good idea how to write to a buffer
efficiently (memory allocation-wise). That is, instead of fprintf what do we do?
I have not updated the RFC with anything related to item 4 though...
Steve
>>> Tamas Szekeres <szekerest at GMAIL.COM> 06/15/07 4:17 AM >>>
Steve,
Here are my comments/questions inline:
1.Each function would need to remove restrictions for duplicate
properties. That is setting a parameter twice should not generate an
error as is does now.
Does this change alter the current behaviour when loading the
configuration from the mapfile. IMO it isn't a big problem if a
parameter is overwritten by another if it have been specified twice.
2.Properties with allocated memory (e.g. char *) should be free'd
if they already have values and are being updated.
Did you mean simply calling freeObject (freeLayer, freeClass etc.) to
accomplish this task? However some of these functions can only be
called when the refcount reaches zero as of the changes related to
RFC24.
3.the object main keyword (e.g. LAYER or CLASS) should be allowed
as a token within that object loader. That would allow entire
definitions to be passed without throwing an error. That token would
simply be skipped in the switch statement.
If I understand correcly when loading a layer the entire map
definition can be passed. Each of the LAYERs will be parsed but the
last LAYER definition wins. Am I right?
Further comments:
It would be considerable to implement the inverse operations as
writing the objects to strings. This addition along with the proposed
one, would provide persistency support for the mapscript objects and
would be a feasible way to preserve the state among various
requests/sessions.
Best regards,
Tamas
2007/6/15, Steve Lime <Steve.Lime at dnr.state.mn.us>:
> Hi folks: In the mad rush to get these defined, I have another one. Please see:
>
> http://mapserver.gis.umn.edu/development/rfc/ms-rfc-31
>
> Steve
>
More information about the mapserver-dev
mailing list