[fdo-internals] FDO PostGIS provider developments

[Jason Birch]

Hi Orest,

I don't think that there's any argument that the current provider is
deficient, but at the same time I don't think performance comparisons are
all that useful.  The current version is incredibly slow compared to other
implementations of PostGIS connectivity (for instance, in uDig, QGIS,
MapServer, etc), so six times faster than incredibly slow may not be equal
to good.  To use performance as an argument for switching implementations,
I'd want to see comparisons against the same data for King.Oracle, SDF, etc.

I think this boils down to a single argument. The way I see it, moving this
provider into the Generic RDBMS framework precludes the possibility of
future non-ADSK involvement in the development and maintenance of the
provider.  I base this on the level of frustration that Mateusz had coming
up to speed on the framework initially, and the number of special cases that
had to be implemented which culminated in him feeling that in the long run
it was better for the community to re-implement from scratch than to
continue working within the framework.  Paul's summary of this decision to
the list, after several months of painful work (which generated the code
you're planning to take over) highlights these problems:

http://n2.nabble.com/fdopostgis-td2050070.html#a2050070

So, you're balancing this argument against immediate cost and long term
maintenance for the ADSK developers, which makes a lot of sense from your
perspective and is understandable.  This does mean, however, that there is
almost no potential for non-ADSK involvement in future development and
enhancements to the provider.  By doing this, you are essentially deciding
to take development of this provider entirely inhouse, and committing to its
future support and enhancement.  This doesn't really bear on this argument
but I have to say that my impression has been that there has been more ADSK
support for desktop features / enhancements than for the sheer performance
required for scalable web mapping.

Anyway.... The FDO (and MapGuide) development communities are still very
much in the fledgling state of development and, in my personal opinion,
decisions like this one will have a strong influence on whether we have the
potential to ever move beyond this stage.

Jason


2009/11/29 Orest Halustchak

>  In the end, we determined that taking the earlier code base, adding
> support for the recent fdo interface changes, and completing other parts
> that weren’t finished would take much less time. Also, based on performance
> comparisons, we would get something that was much faster on inserts and
> selects, e.g. the select performance is about six times faster and schema
> describe is about three times faster. We couldn’t compare insert times very
> well because the current provider kept crashing after a certain point and we
> couldn’t insert a large number of features.
>
> At the same time, we are planning to change the connection parameters to
> separate out the database name from the service name. This will make it
> easier for users. They can identify the service (e.g. localhost:5432), and
> then see the available datastores from which they can choose in a UI. Then,
> PostGIS schema simply will map to FDO schema. The main drawback to this is
> that any users with existing MapGuide feature sources and layer definitions
> will have to update them.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20091130/ad0ca660/attachment.html