[mapguide-internals] RE: PATCH: Raster stability fixes, ticket#462

[Jason Birch]

Bruce,

I understand your reluctance to introduce new code at this point, but I worry that releasing another version of MapGuide Open Source with the current set of defects will slow adoption even further and turn off folks who are currently implementing.  I've lost track of the people I've talked to who either elected to stay at 1.2, or gave up on the MGE/MGOS migration entirely and went to ESRI instead, solely because of stability issues.

MGOS 2.0 was not production ready and in my experience 2.1 is still not production ready.  Releasing it at this point and requiring users to wait an additional year for 2.2 will further decrease adoption and increase community frustration.  I personally see the inherent problems with the FDO connection manager, and the problem with not reusing TCP connections for the Windows (ISAPI?) client to be blockers for this release.  I recognise that perfection is the enemy of done, but I also feel that as a project we should not be beholden to a fixed release cycle and if there are critical issues they should be addressed prior to release.

Jason

-----Original Message-----
From: Bruce Dechant
Sent: March-30-09 8:47 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] RE: PATCH: Raster stability fixes, ticket#462

Traian - Thanks for investigating this over the weekend, much appreciated!

Anyways, for the 2.1 release of MapGuide I think we should incorporate the reference count fix to the GDAL provider - this should be done regardless as Traian has already pointed out the weak reference to the FDO connection in the reader is bad. I don't think we should make significant changes to the FDO connection manager this close to release.

Post 2.1 release the FDO connection manager should be more closely looked at to see what can be done to more easily handle single threaded providers and to perhaps get rid of the reference count dependency for determining if a FDO connection is still in use. This may require an additional FDO API so the provider could just tell the server if the connection is in use. 

Thanks,
Bruce