<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Hi Haris,<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I see what you’re saying about keeping the old provider,
but it would be extra work to maintain the two copies. The old one would still
be available in the 3.4 branch and the new one in the trunk. Maybe that would
be sufficient?<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Thanks,<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Orest<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
fdo-internals-bounces@lists.osgeo.org
[mailto:fdo-internals-bounces@lists.osgeo.org] <b>On Behalf Of </b>Haris
Kurtagic<br>
<b>Sent:</b> Monday, November 30, 2009 11:03 AM<br>
<b>To:</b> FDO Internals Mail List<br>
<b>Subject:</b> Re: [fdo-internals] FDO PostGIS provider developments<o:p></o:p></span></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>I understand that without resources nothing of those would
be done. I think it is great think that Autodesk would allocate resources to
create new FDO provider for PostGIS and I think it is fine that you decide in
which way to work..<o:p></o:p></p>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>My question was , is it necessary to replace old
provider? Could old provider stay there at least for some time after release of
new PostGIS provider ?<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'>Haris<o:p></o:p></p>
<div>
<p class=MsoNormal>On Mon, Nov 30, 2009 at 4:55 PM, Greg Boone <<a
href="mailto:greg.boone@autodesk.com">greg.boone@autodesk.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='font-size:11.0pt;color:#1F497D'>Hi Haris,</span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='font-size:11.0pt;color:#1F497D'>One of the problems that the PostGIS
provider user-community are experiencing is a lack of development support from
the community on some fairly fundamental problems including connectivity,
schema management, stability, and unit testing. In all honestly, the current
code base as it stands simply does not meet the standards expected of a robust
real-world deployment into a customer site. In Orest’s email, he outlined
a number of issues that have been identified as road-blocks, and are not on
anyone’s radar to address in the 3.5 timeframe. While the GenericRDBMS
code base is slightly more complex, it has been proven to work, and work
extremely well. Stability is not an issue. Performance and schema management
are sound. Memory management is under control, etc. </span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='font-size:11.0pt;color:#1F497D'>If you strongly feel that the current
code base is the better option, how would address the fundamental problems seen
in the current code base, so that the provider could be successfully deployed
to customer sites in the 3.5 release timeframe?</span><o:p></o:p></p>
<div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='font-size:11.0pt;color:#1F497D'>Things that still need a fair bit of
work include:</span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<p><span style='font-family:Symbol;color:#1F497D'>·</span><span
style='font-size:7.0pt;color:#1F497D'>
</span><span style='color:#1F497D'>Creating new schema and new data store</span><o:p></o:p></p>
<p><span style='font-family:Symbol;color:#1F497D'>·</span><span
style='font-size:7.0pt;color:#1F497D'>
</span><span style='color:#1F497D'>Spatial filter handling</span><o:p></o:p></p>
<p><span style='font-family:Symbol;color:#1F497D'>·</span><span
style='font-size:7.0pt;color:#1F497D'>
</span><span style='color:#1F497D'>Huge memory leaks on insert.</span><o:p></o:p></p>
<p><span style='font-family:Symbol;color:#1F497D'>·</span><span
style='font-size:7.0pt;color:#1F497D'>
</span><span style='color:#1F497D'>Not all schema commands are implemented.</span><o:p></o:p></p>
<p><span style='font-family:Symbol;color:#1F497D'>·</span><span
style='font-size:7.0pt;color:#1F497D'>
</span><span style='color:#1F497D'>Enable and fix transaction support.</span><o:p></o:p></p>
<p><span style='font-family:Symbol;color:#1F497D'>·</span><span
style='font-size:7.0pt;color:#1F497D'>
</span><span style='color:#1F497D'>Constraint and default values support.</span><o:p></o:p></p>
<p><span style='font-family:Symbol;color:#1F497D'>·</span><span
style='font-size:7.0pt;color:#1F497D'>
</span><span style='color:#1F497D'>Lots of TODOs spread all over the code</span><o:p></o:p></p>
<p><span style='font-family:Symbol;color:#1F497D'>·</span><span
style='font-size:7.0pt;color:#1F497D'>
</span><span style='color:#1F497D'>Virtually no unit tests exist.</span><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
</div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='font-size:11.0pt;color:#1F497D'>Greg</span><o:p></o:p></p>
<div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span
style='font-size:10.0pt'>From:</span></b><span style='font-size:10.0pt'> <a
href="mailto:fdo-internals-bounces@lists.osgeo.org" target="_blank">fdo-internals-bounces@lists.osgeo.org</a>
[mailto:<a href="mailto:fdo-internals-bounces@lists.osgeo.org" target="_blank">fdo-internals-bounces@lists.osgeo.org</a>]
<b>On Behalf Of </b>Haris Kurtagic<br>
<b>Sent:</b> Monday, November 30, 2009 10:26 AM<br>
<b>To:</b> FDO Internals Mail List<br>
<b>Subject:</b> Re: [fdo-internals] FDO PostGIS provider developments</span><o:p></o:p></p>
</div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p>
</div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I
wouldn't like to go to much into discussion about generic rdbms stuff. I think
that priority should be having good PostGIS provider which we can get with
current resources.<o:p></o:p></p>
<div>
<div>
<div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Just
in short, when I started looking how to make provider for Oracle, Generic RDBMS
was first place to start looking. For me Generic RDBMS was to complex , hard to
work with and extend . Performance was also bad.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>That
was few years ago, I would assume that it has improved since but still I am
afraid that Autodesk would be only maintaner of that code. That would be
main reason why I would like to have current PostGIS available, which has not
only Autodesk developers which could work on it.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Haris<o:p></o:p></p>
</div>
<div>
<div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'> <o:p></o:p></p>
<div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On
Mon, Nov 30, 2009 at 2:36 PM, Zac Spitzer <<a
href="mailto:zac.spitzer@gmail.com" target="_blank">zac.spitzer@gmail.com</a>>
wrote:<o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>2009/12/1
Haris Kurtagic <<a href="mailto:haris@sl-king.com" target="_blank">haris@sl-king.com</a>>:<o:p></o:p></p>
<div>
<p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>> Is
it necessary to replace current version, can't that be another
version of<br>
> provider ?<br>
> I was never able to get comfortable with generic rdbms stuff. In my
opinion<br>
> there are minuses too.<o:p></o:p></p>
</div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>like?<o:p></o:p></p>
<div>
<div>
<p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><br>
> I would like to have option of current code base to be continued if there<br>
> would be option at least for some time.<br>
> Haris<br>
><br>
> On Mon, Nov 30, 2009 at 2:14 AM, Orest Halustchak<br>
> <<a href="mailto:orest.halustchak@autodesk.com" target="_blank">orest.halustchak@autodesk.com</a>>
wrote:<br>
>><br>
>> Hi,<br>
>><br>
>><br>
>><br>
>> Autodesk has had interest from Map3D customers who want to use the FDO<br>
>> PostGIS provider to access and edit data using Map3D and other
products.<br>
>><br>
>><br>
>><br>
>> These customers have not been able to use this provider reliably with<br>
>> Map3D. We had a close look at the provider code to determine what work
would<br>
>> be needed to complete the implementation of schema and edit support
and fix<br>
>> other issues. Unfortunately, we found that the provider as it stands
today<br>
>> requires a lot of work to complete the implementation of required FDO<br>
>> interfaces and to add good unit test coverage. Things that still need
a fair<br>
>> bit of work include:<br>
>><br>
>> · Creating new
schema and new datastore<br>
>><br>
>> · Spatial
filter handling<br>
>><br>
>> · Huge memory
leaks on insert.<br>
>><br>
>> · Not all
schema commands are implemented.<br>
>><br>
>> · Enable and
fix transaction support.<br>
>><br>
>> · Constraint
and default values support.<br>
>><br>
>> · Lots of TODOs
spread all over the code<br>
>><br>
>> · Virtually no
unit tests exist.<br>
>><br>
>><br>
>><br>
>> We looked at the level of effort needed to complete that work. It was<br>
>> quite high. So, we looked at an alternative. There exists an earlier
open<br>
>> source community code base for a PostGIS provider that was started a
couple<br>
>> of years ago but not finished. That code base used the generic rdbms<br>
>> framework that is shared with the SQL Server Spatial, MySQL, and ODBC<br>
>> providers. Most of the schema processing is handled with that shared
code.<br>
>> We spent some time working with the current provider and the other
code base<br>
>> to determine the most efficient way to get to a completed provider
that<br>
>> would be robust, perform well, and be maintainable.<br>
>><br>
>><br>
>><br>
>> In the end, we determined that taking the earlier code base, adding<br>
>> support for the recent fdo interface changes, and completing other
parts<br>
>> that weren’t finished would take much less time. Also, based on
performance<br>
>> comparisons, we would get something that was much faster on inserts
and<br>
>> selects, e.g. the select performance is about six times faster and
schema<br>
>> describe is about three times faster. We couldn’t compare insert
times very<br>
>> well because the current provider kept crashing after a certain point
and we<br>
>> couldn’t insert a large number of features.<br>
>><br>
>><br>
>><br>
>> So, what we would like to do is complete our work to get a working
PostGIS<br>
>> provider and then replace the current open source code with our new
copy.<br>
>> Note that we plan to use native PostGIS schema without adding
additional<br>
>> metadata tables just as the current provider does. It will be able to
read<br>
>> any schemas created by the current version of the provider and itself
will<br>
>> generate generic PostGIS schemas.<br>
>><br>
>><br>
>><br>
>> We’ll need to submit an RFC for this, but we wanted to get this<br>
>> information out to you ahead of time.<br>
>><br>
>><br>
>><br>
>> At the same time, we are planning to change the connection parameters
to<br>
>> separate out the database name from the service name. This will make
it<br>
>> easier for users. They can identify the service (e.g. localhost:5432),
and<br>
>> then see the available datastores from which they can choose in a UI.
Then,<br>
>> PostGIS schema simply will map to FDO schema. The main drawback to
this is<br>
>> that any users with existing MapGuide feature sources and layer
definitions<br>
>> will have to update them.<br>
>><br>
>><br>
>><br>
>> In the end, we will end up with a good functioning provider that
performs<br>
>> well.<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> Regards,<br>
>><br>
>> Orest.<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> fdo-internals mailing list<br>
>> <a href="mailto:fdo-internals@lists.osgeo.org" target="_blank">fdo-internals@lists.osgeo.org</a><br>
>> <a href="http://lists.osgeo.org/mailman/listinfo/fdo-internals"
target="_blank">http://lists.osgeo.org/mailman/listinfo/fdo-internals</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> fdo-internals mailing list<br>
> <a href="mailto:fdo-internals@lists.osgeo.org" target="_blank">fdo-internals@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/fdo-internals"
target="_blank">http://lists.osgeo.org/mailman/listinfo/fdo-internals</a><br>
><br>
><br>
<br>
<o:p></o:p></p>
</div>
</div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='color:#888888'>--<br>
Zac Spitzer<br>
Solution Architect / Director<br>
Ennoble Consultancy Australia<br>
<a href="http://www.ennoble.com.au" target="_blank">http://www.ennoble.com.au</a><br>
<a href="http://zacster.blogspot.com" target="_blank">http://zacster.blogspot.com</a><br>
+61 405 847 168</span><o:p></o:p></p>
<div>
<div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>_______________________________________________<br>
fdo-internals mailing list<br>
<a href="mailto:fdo-internals@lists.osgeo.org" target="_blank">fdo-internals@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/fdo-internals" target="_blank">http://lists.osgeo.org/mailman/listinfo/fdo-internals</a><o:p></o:p></p>
</div>
</div>
</div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
<p class=MsoNormal style='margin-bottom:12.0pt'><br>
_______________________________________________<br>
fdo-internals mailing list<br>
<a href="mailto:fdo-internals@lists.osgeo.org">fdo-internals@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/fdo-internals" target="_blank">http://lists.osgeo.org/mailman/listinfo/fdo-internals</a><o:p></o:p></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</div>
</body>
</html>