MapServer Development Process?

[Mark Cave-Ayland]

Hi everyone,

> -----Original Message-----
> From: UMN MapServer Developers List 
> [mailto:MAPSERVER-DEV at lists.umn.edu] On Behalf Of Steve Lime
> Sent: 23 June 2005 23:36
> To: MAPSERVER-DEV at lists.umn.edu
> Subject: Re: [UMN_MAPSERVER-DEV] MapServer Development Process?

(cut)

Just a bit of background: I'm a long term mapserver user, short term
mapserver hacker with a background in CS as opposed to GIS. So please bear
this in mind when looking at my comments below.

> > I like the voting idea, and I think we should adopt it. I also think
> > that votes should be weighted by the number of tests that you have 
> > written and committed to CVS ;) That was a joke. A voting 
> system will 
> > require better communication. The Apache projects demand 
> that all code 
> > decisions take place in the open, and we should adopt this as well. 
> > This means that decisions will not be made between Howard 
> and I on IRC, 
> > or behind closed doors at DM Solutions. In the open means on the 
> > mapserver-dev list. We do a fair job of this, but it could 
> be better. 
> > Writing this in stone and holding each other to it could 
> help to head 
> > off future problems.

Creating a core team would definitely be a good idea. At the moment, I find
it's difficult to see who to aim proposals at when looking at new ideas (at
the moment I think that reports just get posted on bugzilla which CCs to
mapserver-bugs before someone picks it up). I think that discussing new
features/proposals on mapserver-dev would be better as it would allow a much
wider audience to participate in development.

> > It's also long past time to have some tests for MapServer. I propose
> > that we start with the new input plugins: no plugins 
> committed without 
> > tests. These should be tests that can be run under 
> valgrind, and should 
> > also be automate-able.
> 
> I have no problems with this. The process for writing tests, 
> submitting them and so on needs to be well documented and 
> understood by those doing development.

This is good idea, and could really be helped by defining a modular
interface between sections. At the moment, I tend to find that the code
jumps between functions in files calling functions where needed.
Modularisation should also help minimise the impact of any changes across
the system since there would be more of a guarantee that a change in one
place would not subtly break something in another.

> > My last point is not so much about process as about direction and
> > design. I cracked Frank up after the conference by asking what he 
> > thought about how successful Apache became following a complete 
> > re-write. I was only half joking. MapServer, as a prominent 
> user said 
> > to me, has no architecture. Do we put off creating an architecture 
> > until it becomes practically impossible to add new useful 
> features? It 
> > seems to me that GRASS got in trouble this way. Do we 
> really want to 
> > wait until MapServer is widely perceived as clunky and 
> fragile before 
> > making a change?
> 
> I don't know that I agree with no architecture. It's not 
> perfect but then what is. The
> map->layer->class/shape architecture works pretty well for 
> what it was 
> map->layer->intended. I'm
> not at all for re-writes for the sake of re-writing. If you 
> see opportunities then by all means speak up and make some 
> proposals. I'm not afraid of major change if there are good 
> reasons to do so.

I think that the *logical* architecture works well, but I have to be honest
and say that the architecture of the code makes it very difficult for new
developers to jump in and make changes. As an example, here is my
gotcha/wishlist just after hacking on mapserver a short time:


	- Sometimes files contain functions I wouldn't expect based upon
their name
	e.g. mapfile.c contains projection routines

	- More comments - some sections can appear very cryptic at times

	- Sometimes #ifdefs make the code very hard to read, e.g. #ifdef
PROJ tends
	to be sprinkled around like sugar. It would be great if a set of
projection
	wrapper functions could be written that either did the reprojection
or returned
	the source data unaltered; then hopefully a lot of the code could be
pushed
	into a single file

	- Recompilation. If you suddenly need a new INPUT or OUTPUT function
you need to 	recompile everything (dynamically loading libraries for
these features would be 	nice)

	- No obvious API for accessing objects like mapObj, layerObj etc.,
including dynamic 	creation to get over the limits of fixed-sized
arrays. There has been some work to 	fix this (I think to help with
Mapscript) but the code is not necessarily organised 	by object. Something
like mapobj.c, layerobj.c etc. with associated .h files 	containing
extern declarations for their API would be a fantastic help

	- As a result of the above, a lot of expressions are generated as
strings and
	fed into the loadXString routines, so the parser code gets called in
places
	where you may not expect

	- The error reporting in the parser can throw up some of the most
cryptic error
	messages I have seen, and often this doesn't make it out to the
browser

	- There is still some assumptions that the mapserv executable rather
than mapscript
	is being used, e.g. calling mapObj->drawQuery() without having set a
layer template
	in mapscript still gives a blank image

	- And finally, the one that always bites me is that most of source
is space indented
	instead of tab indented which plays havoc with my text editor and
makes indent
	formatting very time consuming
	

Having said that though, mapserver does exactly what it says on the tin, and
it does it well when you get it right. It's just that sometimes the minor
quirks and inconsistencies from the current architecture come and bite you
when you least expect.


Kind regards,

Mark.

------------------------
WebBased Ltd
17 Research Way
Tamar Science Park
Plymouth
PL6 8BT 

T: +44 (0)1752 797131
F: +44 (0)1752 791023
W: http://www.webbased.co.uk