Hi Orest,<div><br></div><div>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.</div>
<div><br></div><div>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: </div>
<div><br></div><div><a href="http://n2.nabble.com/fdopostgis-td2050070.html#a2050070">http://n2.nabble.com/fdopostgis-td2050070.html#a2050070</a></div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Jason</div><div><br><br><div class="gmail_quote">2009/11/29 Orest Halustchak<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal">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.</p>
<p class="MsoNormal">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.</p></div></div></blockquote></div></div>