[Mapserver-dev] FastCGI and MapServer 4.4

[Sean Gillies]

On Sep 27, 2004, at 4:30 PM, Daniel Morissette wrote:

> Sean Gillies wrote:
>> I think that we should reserve some time to shake the bugs out after
>> the new connection pooling and make sure that it is ready for use with
>> mapscript before releasing 4.4.
>
> Well, if it's compiled out then that may not be necessary. Compiled 
> out means to me that the code is there, but shouldn't be considered 
> part of the release: it's only there for those who know what they're 
> doing. This is what was done with the WCS code in 4.2: the WCS stuff 
> was there, but was not considered part of the release and was disabled 
> so that only those who knew what they were doing could try to enable 
> it.
>
> How about the following: 4.4 could have connection pooling available 
> only for FCGI (and compiled-out by default), and 4.5/4.6 could bring 
> enhancements to MapScript to take advantage of connection pooling. 
> Unless of course your changes to MapScript would be minimal and could 
> be done fairly quickly. I fear that if all this is ported to MapScript 
> and all, then it becomes impossible to keep things compiled out in 4.4 
> by default.
>

The mapscript work would be minimal: expose the connection pool as an 
object
and a very simple API to hook it up to layers.  I wouldn't indulge in my
special connection sharing needs, just a straight forward adaptation of
Frank's work that we could use in SWIG and PHP mapscripts.  A mapscript
interface would also make it very easy to write many tests.

>
>> The 4.2.0 release was somewhat broken.  Maybe we could agree if we'd
>> like the 4.4.0 to be more or less bug free, and ask if a longer period
>> between feature freeze and release than last time will help?
>
> 4.0 was broken, but I always felt that 4.2 was a very good release. I 
> guess it depends on how you look at it. What do you consider a broken 
> release?
>
> I agree that we need some time after the code freeze to address any 
> bugs that may be found, but we have to keep in mind that the world 
> doesn't stop to turn while we're in the release process, so we can't 
> take too long before we release. We have to either branch early and 
> constantly make fixes in two branches, or block new developments for a 
> while until we consider the software stable enough to branch the 
> stable release.
>
> In the case of 4.2, the time between the code freeze (And CVS branch) 
> and official release was 5 weeks: beta1 on April 17, followed by beta2 
> and beta3, and finally 4.2.0 on May 25th. And the resulting 4.2 wasn't 
> bad at all in my opinion. I was hoping that we could do the same for 
> 4.4.
>
> Daniel

Sounds good to me.

Sean

--
Sean Gillies
sgillies at frii dot com
http://users.frii.com/sgillies