[mapserver-users] simplicity

[Gerald Thornberry]

I've not yet had the pleasure of creating a MapServer application, though
I've been lurking on this list for about a year and a half.  While I would
also like it to be super-simple, I realize that time is at a premium for
developers of projects like this.  Then with so many possible combinations
of OSs, output formats, webservers, geodata types, preferred programming
languages, etc., creating explicit documentation for each scenario is
overwhelming even for an organized group of doc writers.  Besides, writing
documentation always takes a backseat to writing code unless you're being
paid to do so.  Coding is the fun part after all.

Since I haven't attempted a MapServer install yet, I must ask those in the
know:  if all of the right packages are properly installed prior to trying
to compile MapServer, would it compile correctly every time?  In other
words, if I knew that for my intended use of MapServer that I needed gdal,
php, and libjpeg -- and installed them before I even tried to compile
MapServer -- would it work?

If the answer is yes, would it then be possible to create an online wizard
that a potential user could run through that would help them identify
tools and versions they would need to install (or verify that they have
already installed) in order to accomplish their goals with MapServer?  

For example, categorize elements to help the user identify how they plan
to implement MapServer:

Select the OS:  OpenBSD | pick-a-Linux | Windows flavors | Mac OS X

Select webserver platform:  Apache | IIS | some-Java-thingy

Select geodata source(s):  shapefiles | ArcSDE | PostGIS | etc...

Select output image format:  GIF | JPG | PNG | PDF 

Select fonts:  cool True Type ones | lame'o ugly ones

Select other features until you're out of options...

The user would ultimately receive a checklist of prerequisite packages and
proper versions to install (or verify are installed).  Consequently,
developers could compile stats on options that users want most often, and
users could see the full variety of options in an outline format, which is
easier to digest at the outset of this type of project than pages of
documentation (though I'm not suggesting that it is a substitute for good
docs).  Anyway, enough run-on sentences.  I just thought I'd try to help
and then cowardly run away.  I don't want to write documentation either.

Gerald Thornberry
Technical Support Manager
Spatial Data Integrations, Inc.


On Wed, 26 Dec 2001, Stephen Lime wrote:

> Greetings: I'm all in favor of making the software easier to install and use, and would back the formation of groups to coordinate the distribution of binary releases for various platforms. I think the UMN would need to play a role in making that happen, much like their role in getting documentation put together. The development team plays a role in making the software actually buildable under a variety of circumstances. We probably need a document that lays out exactly what you need to build the code, or at least explains what each supporting library brings to the table.
> 
> On a couple of other comments:
> 
> - Including everything in the distribution: nope, ain't gonna happen. Simply too hard to keep up-to-date, not to mention legal issues associated with some of the commercial packages that can be tied into.
> 
> - Some compilation issues can't be mitigated ahead of time. I mean if you have GD installed on your system and it doesn't support GIF or whatever then the solution is to re-build GD. What can be done is to provide a forum for advice on how to work around these issues. The mailing list is one way, formal forums would be another. There are plans for a series of MapServer Wikis that could address the various topics identified by Puneet in the first message in this thread. The biggest pain in building MapServer with static libs is dealing with all the friggin libraries installed on the box. This is esspecially true on Linux machines.
> 
> - MapServer isn't really all that different from other OpenSource applications. Try building Gimp from scratch. What is different is the audience- which is broader and in some cases less technical. Fact is that maps are a cool thing to add to a website. If your machine has the right base libraries installed then making the software is trivial, getting to that point is the hard part.
> 
> The biggest impediments in widespread use of MapServer are not related to the internals of the software (what it can and can't do), they are productivity issues: easy installation, quality documentation and easy application configuration. I've known this for quite a while, but seeing as I can only work on this evenings after my kids go to bed there's no way I can spearhead the effort. So, everyone agree's there is a problem but is anyone willing to commit some time to making it happen?
> 
> Steve