Allow me to elaborate :) Some examples of things I ran into:
- How to support different versions of mapserver, and mapfiles: Try to create the concept of "schemas" for mapfiles, and turn mapfiles into DOM-like structured instances, and dynamically loading the right mapscript version, and so on ... This makes another case for XML mapfiles, or at least a more rigid structure for the existing syntax. - For the OO thing: MapServer does not abstract a lot of it's dependencies into consistent interfaces. So someone who writes code around mapscript needs to do a lot of a various conditional checking and adapt around many possibilities. Case in point: Last I checked, I couldn't get a list of attribute names for a given data source from MapServer proper. I need to know it's a shapefile, use a third party DBF module, and do the work manually. If the data source is postgis, I need a whole different set of code and exceptions, and so on ... Knowing MapServer itself is already compiled against all these things, I start seriously feeling like I'm re-inventing the wheel, and adding more and more dependencies ... Which is not long-term sustainable. This is where I stopped :) I think the general approach to mapserver development should be first and foremost a "library" ... Around which various things (Like the CGI, or PHP/Python module) are implemented. This forces a more abstract and consistent API, easier to re-use. Also seperates it from being "web-bound", allowing use in other environements, namely, in this case, desktop apps. I know there's efforts going on re: a pluggable input driver framework, which I think is fantastic ... I think mapserver needs more efforts like this towards modularity. Having looked at Eclipse's Plug-In framework for this exact purpose, I can assure you, much of these same issues would come up there too ... Operating strictly on MapFiles as text can be done easily enough (In Python, I have an ElementTree driver for them for example! Which I should really share at some point :P), but once you bring in MapScript and Map Rendering and true user interactivity, that's a whole other ball game. My .02$ J.F. -----Original Message----- From: Sean Gillies [mailto:[EMAIL PROTECTED] Sent: December 14, 2005 11:41 AM To: Doyon, Jean-Francois Cc: [email protected] Subject: Re: Foundation and Mapserver MAP file manag e tool J.F., I don't think a MapServer workbench (since "Studio" is taken) would necessarily need to be any more OO than MapServer itself. All you need to start is to allow people to visualize and save style, class, and layer mapfile fragments, and then mix fragments together into a single mapfile for export. IIRC, there is even some very preliminary support in MapServer for instantiating objects from mapfile fragments. cheers, Sean On Dec 14, 2005, at 9:13 AM, Doyon, Jean-Francois wrote: > I agree for the need for such a tool ... We've been dying for one > here. I also don't think it should be web based, but something that > geographers/cartographers could easily use, so a desktop application, > a la "Workbench"/ArcMap/etc ... > > I actually started writing one using Python/wxPython! But quickly ran > into issues with some of the design of MapServer, and problems > integrating it into a desktop app (vs. the web). If anyone is > curious, I could share my experiences in this department. > > I've since discovered and learned to love Eclipse though, so there's > definite potential there! That'd imply a well supported Java > MapScript though ... Is it mature? (And even then, as I suggested, > some changes to mapserver would be necessary, bringing a C program > into a purre OO world presents interesting challenges ...). > > Such a project could eventually find itself in the foundation, but > yes, it's inception should be community driven. > > J.F. --- Sean Gillies sgillies at frii dot com http://zcologia.com/news
