[mapserver-dev] Re: feedback on possible mapserver enhancements

[Daniel Morissette]

I have not looked at TinyOWS yet, but do we really need to integrate 
TinyOWS into MapServer? Since we all agree that this is a large chunk of 
work and would be very disruptive for MapServer, could we not simply 
tell users who need a non-Java WFS-T to use TinyOWS alongside MapServer?

I have always been the main advocate of the "MapServer for WMS, 
GeoServer for WFS" approach, but for many organizations that's not an 
option because that means having to setup and maintain a second server 
infrastructure just to get WFS-T.

Perhaps all we need is to make a minimal effort to make it easy to deply 
TinyOWS on an existing MapServer installation. Presumably that just 
means installing the tinyows binary in the cgi-bin directory (is TinyOWS 
a CGI?). Also, packaging TinyOWS as part of MS4W would go a long way for 
Windows users.

What do you think Thomas?

Daniel


thomas bonfort wrote:
> (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
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev


-- 
Daniel Morissette
http://www.mapgears.com/