[mapserver-users] mapserver-dev list? (was: XML mapfile?)

[Steve Lime]

ESRI's not stupid, there are many a thing to learn from their
implementations, and those of other vendors. I personally take it as a
compliment when compared favorably with ArcIMS. Moving forward without
looking at others are doing would be foolish on our part.

The most compelling argument for the use of XML in my mind is
simplification of the mainentenance of map files. If I understand this
right you have 2 options (please correct me where I stray from
reality):

  1: parse XML or current map file syntax into the current C structures
and proceed as normal
  2: load XML directly to a DOM structure and pass that around in place
of the mapObj

Option 1 is what can be looked at short term as there are some benefits
to using external XML tools, as alluded to in an earlier message. This
option doesn't make maintanence any more palatable. Option 2 is where
it's at. To add functionality you do it by having functions recognize
new parameters. Nothing to do on the input end, since the parameters are
all held in a neutral format and read by standard tools. I guess you'd
just have to edit a schema or whatever so that defaults are properly
handled. In that enviroment MapScript would be greatly simplified and
would largely consist of: (1) a few methods to get/set portions of the
DOM, and (2) the wealth of methods to actually DO something with it.
Losing the lexer, at least for file parsing (expressions are another
matter), would be a good thing (thread-wise). 

I do think it's worth looking at, and yes showing is always better than
telling...

Steve

Stephen Lime
Data & Applications Manager

Minnesota DNR
500 Lafayette Road
St. Paul, MN 55155
651-297-2937

>>> "C F" <gis_consultant at hotmail.com> 05/23/02 01:59PM >>>
I knew that despite my disclaimers, by mentioning IMS, people would
assume 
that's what I'm shooting for.  All I can say is that is much farther
off the 
mark than I can possibly tell you.  If you want to have an offline 
discussion about that, I'd be happy to.  This gist of the story is that
just 
because a product we don't like uses a particular kind of technology
for one 
piece of it's puzzle, doesn't mean we can't benefit from using the same

technology for our own benefit.  If that was the rule, then I guess 
MapServer wouldn't be a web-base map server... serving up map images
using a 
CGI server component and using web browsers as clients.
It seems like a good portion of the conflict comes between people like
me 
who are interested in building more dynamic, integrated *applications*
vs. 
people who mostly use MapServer as a simple, install-and-go map
server....  
That's oversimplifying and not a catch-all, but I'm just trying to
focus the 
conversation.  A lot of stuff has been thrown into the mix and is
confusing 
and scaring some people off.
I think for starters, maybe we could throw out the performance issue
for 
now.  Because, to me, it is something that is very debatable but will
not be 
need to be resolved unless we convince people that XML is the way to go

based on functionality.... if the guys with authority think it's worth
a 
shot, THEN we test the feasibility of doing so without losing
performance.  
To answer people's concern about serializing XML DOM objects to a
file.... 
think of it as compiling your C program.  Are interpreted languages
faster 
than compiled languages?  No.  And in as sense it should simplify the 
MapServer code.  It would be harder at first because MapServer is
already 
written for the current MapFile structure... but the result would be
getting 
rid of custom mapfile parsing classes and use standard XML parsers 
instead... less code... less maintenance.  As additional functionality
is 
brought into MapServer that requires additional MapFile structures....
piece 
of cake with XML.  That's progress.
Oops.... I'm straying again... back to the other kind of MapServer
users... 
as people have mentioned before, it's certainly possible to still keep
the 
existing mapfile format, so that shouldn't be your primary concern. 
We're 
simply looking at the possibilty of switching (or adding) a technology
that 
is more standardized and flexible rather than continuing to invent 
proprietary methods.
Okay, I keep promising myself I'm not going to be able to convince
anybody 
by talking... I need to come up with real, working examples, which I
can't 
do if I'm typing email all day.  If I can stay out of here long enough
maybe 
I'll come up with something in a few weeks :)



>From: Richard Greenwood <Rich at GreenwoodMap.com>
>To: mapserver-users at lists.gis.umn.edu 
>Subject: Re: [mapserver-users] mapserver-dev list? (was: XML
mapfile?)
>Date: Thu, 23 May 2002 12:09:35 -0600
>
>Daniel Morissette wrote:
>
>>How about a mapserver-dev list where all new development questions
are
>>discussed without disturbing regular users?
>
>Sounds like a good idea, but not being a developer,  my vote shouldn't

>carry a lot of weight.
>
>Regarding all the hoopla over XML; I've got some questions, or maybe 
>reservations. I'm pretty ignorant of XML, but sometimes a little
ignorance 
>enhances ones objectivity, so here goes. It seems generally accepted
that 
>XML is probably slower than the current map file format and that you
need 
>to serialize the DOM. A CGI program can't hold this serialized object
in 
>memory, so you're going to have to write it out as a new map file, or

>abandon CGI in favor of JSP or a similar technology, no?
>
>In either case the disadvantages would seem to out weight the
advantages: 
>if you write out a new map file, then all you done is written a 
>preprocessor for XML. Why not write one for French, too? <g> If you
abandon 
>CGI in favor of JSP, then you end up with A**IMS, which you can
already buy 
>off the shelf.
>
>And for all of that, what have you really gained in terms of
functionality? 
>The existing CGI mapserver is fast, flexible, portable and easy to 
>configure. Before someone suggests that it be remolded in the image of

>A**IMS, they should take time to get to know mapserver. If it still
doesn't 
>meet their needs, or if CGI is just entirely too retro, then go with 
>mapscript, where, as was stated previously, "the sky is the limit".
>
>Of all the arguments in favor of XML that have been throw out in the
last 
>couple days, the only one that hold any water in my bucket is the 
>possibility of enhanced WMS compatibility. The rest of it sounds like
a 
>desire to push a stolid work horse into a trendy new wrapper.
>
>Rich
>
>
>Richard W. Greenwood, PLS
>Greenwood Mapping, Inc.
>Rich at GreenwoodMap.com 
>(307) 733-0203
>http://www.GreenwoodMap.com 




_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com