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

[Vic Kelson]

"Former" Lurker Here Again,

You know, I've thought a lot about an 'XML-ified' version of Mapserver,
and I've concluded that its a darn good idea to make it work that way
(see my previous long-winded post to the list).  I have also concluded
that we can't efficiently do it purely in parallel with the existing
mapfile format.  To be really useful, the efforts will eventually need a
lot of coordination.  I think it might work to have the existing file
format be the input for a program (mapserv) that internally uses code
objects that may also be manufactured with XML files.  Sort of a special
case of Steve Lime's "Option 2".  Here goes...

In my dreams, I envision a way that the mapserver handles the march of
revisions elegantly, in a manner similar to the way web browsers handle
HTML.  OK, maybe even better than web browsers handle HTML <wink>.  A
proper set of mapserver-related object classes would be terrific, and
code that traverses DOM trees is an easy way to handle all this stuff. 
Furthermore, don't stop with web pages -- it is probably just as easy to
implement and document classes (I prefer python or C++) that are
populated by XML files and may be used for all sorts of things.  For me,
this is the real power of the XML mapfile strategy, and it seems to me
that a natural way to make progress is to leverage the mapscript
library.  

May I propose wrapper classes that manufacture mapscript objects from
XML?  I think python would be a dynamite way to start, since it does
pretty darn good OO, it's easy to learn, it has nice XML processing
tools, it's very productive to code in, and mapscript/python exists. 
The wrapper would read an XML file ("MapservML"?), and traverse the DOM
tree, using mapscript methods to populate the internal data structures,
do rendering/queries, etc.  The constructor would then return an object
that could be used for lots of other things, e.g., adding layers made
from local data, rendering to a bitmap/ps/pdf/vrml and then allowing
mark-up with "draw line", "draw circle", "draw arrow", "draw text", and
so forth, even allowing drawing in world coordinates!  Also (in python
for example), we could readily make COM/DCOM objects on Windows, so you
could plug the objects into VB/VBA/Office (or make CORBA components). 
It's a functional step toward the ESRI GIS Objects stuff, but it's open
and cross-platform.  Can mapscript make GML or is that a mapserv
function?

For performance reasons, the wrapper might eventually be written in C or
C++ and linked to python/php/perl/[I can't resist saying Scheme for some
reason] for application development.  I'd propose prototyping in python
and converting to C modules later to satisfy performance needs and link
to all those other languages that I don't use <grin>.

Here's the potentially controversial part, and I apologize in advance
for being so presumptuous.  Over time, the mapscript library would
become the base implementation for all the programmatic rendering
innards of mapserver and mapserv would simply be a CGI front-end which
reads the current format and has mapscript objects and an HTML template
generator built into the back-end (incidentally, you could make an
"xml-mapserv" by using an XML file instead of the current format in a
jiffy!).  I suspect it would require decoupling the QUERY stuff from the
LAYER objects (or else put some programmatic glue in mapserv), since the
query template, etc. has no real meaning in a non-mapserv context.  I
apologize because I haven't looked closely at the code -- is it already
done this way?  

To my uneducated eye, it looks like a "reasonably" short trip
(especially if I don't have to write it, HOHO!) from the current
mapserver and mapscript to a set of components that could do so much
more than web sites...  However, it is only realistic to do so if the
effort can eventually be coordinated with mapserver development. 
Eventually it could mean making mapscript expose all the necessary
features of mapserv, and new rendering features, etc. would need to be
in mapscript first, then means to activate them added to mapserv.

Anyone want to try a prototype using the current mapscript?  I'd be
willing to assist with design and python prototyping if we can get a few
folks together (and we'd especially need someone from the "inside" to do
a good job on the DTD)...  Or is this a waste of time?

BTW, hope I don't sound like I think I have all the answers!  I LOVE
Mapserver and its brethren, and I owe a debt of gratitude to everyone
who's worked on it!  I'm also not ignoring PHP or PHP mapscript; they
are both nifty hacks and I use them.  I focusing on python, C++, and
Java (please don't ask me to think about C#, it makes my brain explode),
because they have more robust object-oriented features and are better
suited for general-purpose programming.   Although you can now use PHP
"outside" of web servers, I wouldn't use it that way.  Python saves me
time.  YMMV.

Bye-bye.
Vic

On Thu, 2002-05-23 at 14:33, Steve Lime wrote:

    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 
    
    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-users/attachments/20020523/6666e57d/attachment.html