[MAPSERVER-DEV] feedback on possible mapserver enhancements

[thomas bonfort]

(replying on behalf of camptocamp)

We (camptocamp guys) think that a WFS-T (even a stateless one)
implementation could be meaningfull, mainly because FeatureServer
doesn't (yet ?) handle OGC WFS-T, and GeoServer is Java based
(so it is not always a suitable choice in terms of available technology).

The TinyOWS application (which is a stateless WFS-T CGI server written
 in C upon PostGIS) was born in this context, as an R&D project.
It took time to implement and check OGC units tests, but it was done.

Right now, the question (for us) is, could we imagine to bring that
kind of experience and knowledge related to WFS-T stateless
implementation in C, into MapServer ?

Technically speaking the answer is clearly yes, but it is a fairly large
job.

For the next couple of months all the developers that could work on the
project are fully booked on customer projects. So camptocamp is only able
to give some help, but we can't take the whole thing by ourselves.

So if demand is there, and others are willing to participate, we are
ready to help on this.



On Feb 4, 2008 6:32 PM, Steve Lime <Steve.Lime at dnr.state.mn.us> wrote:
> I'd like to hear feedback from the folks at camptocamp...
>
> Steve
>
> >>> On 2/4/2008 at 11:27 AM, in message
> <2DC5CCA14756424BBBEE8B4B2E4A682F036CEF88 at ecburexch1.ontario.int.ec.gc.ca>,
>
> "Kralidis,Tom [Burlington]" <Tom.Kralidis at EC.GC.CA> wrote:
>
> >
> >> -----Original Message-----
> >> From: UMN MapServer Developers List
> >> [mailto:MAPSERVER-DEV at LISTS.UMN.EDU] On Behalf Of Daniel Morissette
> >> Sent: 04 February, 2008 12:16 PM
> >> To: MAPSERVER-DEV at LISTS.UMN.EDU
> >> Subject: Re: [MAPSERVER-DEV] feedback on possible mapserver
> >> enhancements
> >>
> >> thomas bonfort wrote:
> >> >>> And last but not least :
> >> >>> * what would you think of having a wfs-t implementation for
> >> >>> mapserver, probably at first limited to postgis backends,
> >> and based
> >> >>> on the tinyows project?
> >> >> A year ago I would have said no, but several times in
> >> recent months
> >> >> I've had questions from folks that seem to use WFS-T as a means of
> >> >> selecting their web rendering tool. It's becoming a
> >> differentiating
> >> >> feature. I'm not familiar with TinyOWS though. Are you
> >> suggesting assimilating TinyOWS?
> >> >
> >> > the advantage of this would be to avoid having to deploy another
> >> > server along side mapserver in order to treat the wfs-t side of an
> >> > application,as you pointed out. in finality it would mean
> >> porting of
> >> > the tinyows code into mapserver.
> >> >
> >>
> >> There is so much demand for WFS-T by our users that I am
> >> slowly giving up and starting to think that we may have to do
> >> WFS-T in the end. Please don't tell anyone that I wrote that. ;) ;)
> >>
> >
> > Yes! :)
> >
> >> I am not sure about integrating TinyOWS code... I have never
> >> looked at TinyOWS, but wouldn't a simple merge be messy? How
> >> would that fit with existing mapwfs.c code? Could we not just
> >> extend the current implementation (and make the necessary
> >> architecture changes) to support transactions?
> >>
> >
> > I think extending mapwfs.c with optional transaction would be preferred,
> > IMHO.  Assefa and I discussed this awhile back and mapwfs.c we would
> > need mapwfs.c to handle the messaging and (maybe) maptransaction.c to
> > take care of the lower level stuff (and thus make it available to other
> > interfaces if / when).  Specifying transactional support could either be
> > thrown as a ./configure flag, or a metadata value, depending.
> >
> > ..Tom
>