feedback on possible mapserver enhancements

[Steve Lime]

Users don't seem to buy the install 'em both argument. I think for the real basic use
of WFS-T folks ask why should they bother. So, even basic support for one data 
provider (e.g. PostGIS) may well meet 90% of the demand. Perhaps those folks should
be steered towards feature server...

Personally I have little or no interest in working on WFS-T but if someone else does 
and it doesn't impact other areas of the code then it's worth the debate. Integration 
of an existing solution, providing it's viable, makes the most sense to me. It would be 
somewhat compartmentalized so would likely need little re-engineering. 

Steve

>>> On 2/4/2008 at 11:49 AM, in message
<D58A1CC2-E9C0-4DD5-BDC0-2201B78D6248 at gmail.com>, Howard Butler
<hobu.inc at GMAIL.COM> wrote:
> On Feb 4, 2008, at 11:15 AM, Daniel Morissette wrote:
> 
>> 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. ;) ;)
>>
>> 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?
> 
> 
> MapServer is not a GIS!  MapServer is not a GIS!  I am not supportive  
> at all of implementing WFS-T in MapServer.  What benefit is there to  
> be gained by doing so that can't be accomplished by setting up a  
> GeoServer instance alongside MapServer?  IMO, it is the best-of-breed  
> open source WFS-T that's out there, with tons of momentum and  
> development force behind it -- why go to the trouble to re-implement  
> it in MapServer?
> 
> Technically, one challenge I see for MapServer implementing WFS-T is  
> that MapServer apps generally expect to be transient and stateless.   
> MapServer does not do well in long running processes (any MapScripter  
> who's tried can give you gobs of complaints about this), and it has no  
> concept of transactional operations which I think would be very  
> challenging to bolt on in any smooth sort of way.
> 
> IMO, MapServer should continue to improve upon what it is good at, and  
> WFS-T is not something that I think it would be good at without a lot  
> of re-engineering (we hate churn, remember?).  With some effort, we  
> could have something workable and maybe even functional, but it will  
> get nowhere close to what GeoServer has.
> 
> Howard