feedback on possible mapserver enhancements

[Steve Lime]

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