[mapserver-dev] Expanding the MapServer Project (Next Steps)

Thu Apr 14 13:33:15 EDT 2011

On Mar 30, 2011, at 7:06 AM, Lime, Steve D (DNR) wrote:

Hi,

> Hi all: Reaction has been very positive from all sides and I'd like  
> to keep moving forward. I'm curious what Thomas and Olivier et al.  
> think
> about Frank's idea of RFCs as the start of the process. It's good in  
> that it's something actionable by the MapServer PSC. I'd be happy  
> to, as may
> others, assist in any way necessary.

Attached a first RFC draft related to TinyOWS integration.
Thanks in advance to comment, improve, enhance this first version.

-------------- next part --------------
.. _rfc70:

=========================================================================
MS RFC 70: Integration of TinyOWS in MapServer project
=========================================================================

:Date:  2011/04/14
:Author: Olivier Courtin
:Contact: olivier dot courtin at oslandia.com
:Last Edited: $Date$
:Status: Draft
:Version: MapServer 7.0
:Id: $Id$

Description: This RFC proposes a TinyOWS integration under MapServer Umbrella.

1. Overview
-----------
TinyOWS is often used tiedly with MapServer to provide WFS-T functionnalities.

The idea here is to bring to end user a more integrated solution 
through a single MapFile configuration file for both apps.

And also to put TinyOWS under MapServer project umbrella, to increase again
its usage.

2. The proposed solution
------------------------

2.1 Keeping the cycle release independant
-----------------------------------------
MapServer and TinyOWS cycles releases are kept independant.

2.2 SVN
-------
On SVN, TinyOWS location should be:

 svn.osgeo.org/mapserver/trunk/tinyows
 svn.osgeo.org/mapserver/branches/tinyows-1.0
 svn.osgeo.org/mapserver/tags/tinyows-1.0.0

2.3 A common MapFile as config file 
-----------------------------------
Aim is to be able to have for end user a single config file, so a text MapFile.

TinyOWS trunk already able to deal with MapFile to retrieve all it's config 
stuff, through a dedicaded MapFile lexer.

The idea, in a quite near future, is to bring an LibMapFile API 
and so to allow others apps to use MapFile as a single config file way. 

It will simplify the maintenace of such a parser, and avoid possibility to have
distincts behaviours.

This LibMapFile API, is out of the scope of this RFC.

2.4 Perspective: Packaged build system 
--------------------------------------
We could imagine from this RFC (and also with related mod_geocache integration),
to provide an meta package with a single configure/make/make install, managing
the build of MapServer, TinyOWS and mod_geocache at once.

These meta package build system is also out ot the scope of this RFC.

3. Detailled solution
---------------------

3.1 Documentation
-----------------
Move TinyOWS trac Wiki documentation to RST syntax.

Also need to enhance documentation to provide more examples 
and a comprehensive user manual, or at least something like and FAQ.

Native English writers, and guys who are not (yet) familiar with the project
are really appreciated on helping on this.

3.2 Licence
-----------
TinyOWS already use MIT licence, as MapServer do.
Copyright holders (Barbara Philippot and Olivier Courtin) should be kept 
on existing TinyOWS files.

3.3 Tickets
-----------
TinyOWS use a Trac, but as only few tickets are still open,
an efficient way is just to create them back in MapServer one.

Should imply a new component in MapServer Trac, called: TinyOWS.

3.4 Developpers & PSC  
---------------------
Olivier Courtin should entered in MapServer PSC and have commit access to 
MapServer trunk, and will keep (at least for a while) the lead in the TinyOWS
development stuff.

Others TinyOWS devs are already involved in MapServer project (Assefa, Alan).

One aim is also to have more MapServer devs ready to look at the code,
and committing patches.

3.5 SVN Import
--------------
TinyOWS trunk and 1.0 (coming) branch should be imported in MapServer SVN.

Dunno on this point if we have a way to keep history of previous commits ?
Anyone ?

3.6 Code Convention
-------------------
We have to call astyle on the whole code, to make it MapServer compliant:
astyle --style=kr --unpad=paren --indent=spaces=2

3.7 Redirections
----------------
tinyows.org domain could be redirected to the coming MapServer TinyOWS 
documentation pages.

Mailings lists: tinyows-dev and tinyows-users should be stopped and news
discussions should occurs to relevant mapserver ones.

4. TinyOWS Code Review 
----------------------

4.1 Code Origin
---------------
All C code was written from scratch by TinyOWS devs, so should not be a
real problem.

On the other hand, we have to clarify XSD Schema from W3C, and OGC,
and also OGC CITE Unit tests licence policy (i.e are they really public ?)

4.2 Code Quality
----------------
All code compile without any warning on commons Unix like platforms,
with flags: -ansi -pedantic -Wall

All OGC CITE Units tests are valgrinded, (no error, no memory leak),
but it's doesn't cover all the code branchs.
Some units tests like Cunit could be helpfull in a future.

4.3 Security Audit 
------------------
No external security audit never been perform on the code.
The main inherent risk is SQL Injection.

Somes check already 've been done with automated tools like sqlmap,
but will need to be improved to adjust to some WFS-T and FE 
peculiar uses cases.
(No security hole 've been found on TinyOWS trunk with sqlmap)

4.4 OGC WFS-T compliancy
------------------------
Implementation of WFS 1.0.0, WFS 1.1.0, FE 1.0.0 and FE 1.1.0.
Basic and Transactional profile, SF-0.
(No Xlink nor Lock profile implemented)

TinyOWS trunk on OGC CITE unit test:
 - WFS-T 1.1.0 (r4) : 519 'Passed' / 34 'Failed'

4.5 External Dependancies
-------------------------
 - LibXML2 >= 2.6.20
 - PostgreSQL >= 8.1.0
 - PostGIS >= 1.5.0
 - Flex
 - FastCGI is optional (but recommended)

4.6 MapFile notions not yet addressed
-------------------------------------
Some Mapfile concepts are not yet present in TinyOWS:
 - Supporting other database than PostGIS
 - Ability to associate each layer to a different database connection 
 - Some specifics configuration stuff not required by OGC compliancy, 
   but who still could be usefull.

4.7 Build system
----------------
TinyOWS use like MapServer autoconf and Makefile to build stuff.

4.8 Roadmap and vision
----------------------
General aim is to keep the application the faster alternative available for WFS-T,
as compliant as possible to next OGC and INSPIRE standards, and of course robust.

Mains future works area are (they will imply futures RFC, just here to notice them):
- WFS 2.0 and INSPIRE compliancy
- Apache Module support
- More exhaustive unit tests policy (not only OGC ones)
- More consistent behaviour and configuration directives for both TinyOWS and MS.
- Oracle Spatial support

5. Voting history
-----------------

-------------- next part --------------

--
Olivier