<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:m="http://schemas.microsoft.com/office/2004/12/omml" 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:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@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;}
@font-face
{font-family:"\@SimSun";}
/* 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.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:1165516237;
mso-list-type:hybrid;
mso-list-template-ids:1640006196 -210477944 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;
mso-fareast-font-family:SimSun;
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</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'>As far as I’m concerned this is not a technical or
implementation issue but an API issue. What is more readable and predictable
API?<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'>Badreddine<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>
<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>Traian
Stanev<br>
<b>Sent:</b> Wednesday, September 16, 2009 2:42 PM<br>
<b>To:</b> FDO Internals Mail List<br>
<b>Subject:</b> RE: [fdo-internals] RE: MOTION: FDO RFC 34 - FDO Reader Access
By Index<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></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 think the discussion keeps dancing around the issue without
anybody giving an objective technical reason of why it is impossible for the
order of the properties in the class definition returned by the Select to match
the indices returned by GetPropertyIndex. If it is not impossible, then at
least give some other overwhelming reason of why it should not be done. <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'>The following arguments are not sufficient:<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span
style='font-size:11.0pt;font-family:Symbol;color:#1F497D'><span
style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Existing providers should not have to be forced to change
– as far as I know there are no existing providers implementing this new
API which we are introducing with this RFC.<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span
style='font-size:11.0pt;font-family:Symbol;color:#1F497D'><span
style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>It’s more work to do it like that – the same amount
of work would have to be done on the client side in order to use this feature
if it is not done on the provider side<o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:.25in'><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'>Unless I am misunderstanding things, the default implementation
will actually conform to this, since it will get the indices from the class
definition. Providers which are unwilling to implement uniform indexing can
simply fall back to the default implementation, which will automatically give
them uniform indexing.<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'>The GetClassDefinition call can build up the property collection
in any way it wants. Is there anything stopping it from ordering the collection
of properties based on values returned by GetPropertyIndex?<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'>Traian<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'><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-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>
<div>
<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>Badreddine
Karoui<br>
<b>Sent:</b> Wednesday, September 16, 2009 2:28 PM<br>
<b>To:</b> FDO Internals Mail List<br>
<b>Subject:</b> RE: [fdo-internals] RE: MOTION: FDO RFC 34 - FDO Reader Access
By Index<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Never mind the potential performance improvement, you can also
look at this feature as reducing complexity. If anything, it brings the Fdo
feature reader in line with similar data access API such as ADO.Net; I call
that more familiar and less complex. Also, relying on a documented
behavior such as the reader returning properties in the same order as the class
definition is complex and error prone. I’d rather use an API that is self
documenting than having to dig some rule off some document somewhere.<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'>Badreddine<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>Jason Birch<br>
<b>Sent:</b> Wednesday, September 16, 2009 12:53 PM<br>
<b>To:</b> FDO Internals Mail List<br>
<b>Subject:</b> Re: [fdo-internals] RE: MOTION: FDO RFC 34 - FDO Reader Access
By Index<o:p></o:p></span></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal style='margin-bottom:12.0pt'>I agree with this. <br>
<br>
FDO is already seen as large and awkward by much of the larger open source
community. Anything that can be done to reduce complexity, or at least
not increase complexity, is good.<br>
<br>
Jason<o:p></o:p></p>
<div>
<p class=MsoNormal>2009/9/16 Traian Stanev <<a
href="mailto:traian.stanev@autodesk.com">traian.stanev@autodesk.com</a>><o:p></o:p></p>
<p class=MsoNormal><br>
Hi Dan,<br>
<br>
I think you are right, there are not many places where the performance gain
would be significant -- but they do exist. Imagine a copy from one data source
to another, of a feature class with 100K features and 100 columns -- a common
situation with street network files. For each feature, for each property,
you would have to do a name->index lookup inside the reader provider
(SDF, SQLite, SHP or whatever other provider gets columns by index natively).
Such lookups do get costly once you have lots of columns.<br>
<br>
If given a choice between the RFC34 as it is now and not having access by index
at all, I would choose the latter -- i.e. I'd rather see the RFC withdrawn than
implemented in a way that will require API users to write more code to use it
than if they used access by name. Simply because if it's more work to use
access by index, I don't see people switching their code around to make use of
it.<br>
<span style='color:#888888'><br>
Traian</span><o:p></o:p></p>
<div>
<p class=MsoNormal><br>
<br>
> -----Original Message-----<br>
> From: <a href="mailto:fdo-internals-bounces@lists.osgeo.org">fdo-internals-bounces@lists.osgeo.org</a>
[mailto:<a href="mailto:fdo-internals-">fdo-internals-</a><o:p></o:p></p>
</div>
<div>
<div>
<p class=MsoNormal>> <a href="mailto:bounces@lists.osgeo.org">bounces@lists.osgeo.org</a>]
On Behalf Of Dan Stoica<br>
> Sent: Wednesday, September 16, 2009 9:54 AM<br>
> To: FDO Internals Mail List<br>
> Subject: [fdo-internals] RE: MOTION: FDO RFC 34 - FDO Reader Access By
Index<br>
><br>
> Talking about the performance gain it might be disappointing. The reason
is<br>
> the access by name has been optimized for a number of providers.<br>
><br>
> As for convenience, I'm not very sure either.<br>
><br>
> Dan.<br>
><br>
> -----Original Message-----<br>
> From: <a href="mailto:fdo-internals-bounces@lists.osgeo.org">fdo-internals-bounces@lists.osgeo.org</a>
[mailto:<a href="mailto:fdo-internals-">fdo-internals-</a><br>
> <a href="mailto:bounces@lists.osgeo.org">bounces@lists.osgeo.org</a>] On
Behalf Of Klain Qin<br>
> Sent: Tuesday, September 15, 2009 10:02 PM<br>
> To: FDO Internals Mail List<br>
> Subject: [fdo-internals] RE: MOTION: FDO RFC 34 - FDO Reader Access By
Index<br>
><br>
> Yes, Carsten. You are right. This is exactly the way being proposed for
the<br>
> default implementation as depicted in the RFC.<br>
><br>
> Klain<br>
><br>
> -----Original Message-----<br>
> From: <a href="mailto:fdo-internals-bounces@lists.osgeo.org">fdo-internals-bounces@lists.osgeo.org</a>
[mailto:<a href="mailto:fdo-internals-">fdo-internals-</a><br>
> <a href="mailto:bounces@lists.osgeo.org">bounces@lists.osgeo.org</a>] On
Behalf Of Carsten Hess<br>
> Sent: Wednesday, September 16, 2009 9:39 AM<br>
> To: FDO Internals Mail List<br>
> Subject: [fdo-internals] RE: MOTION: FDO RFC 34 - FDO Reader Access By
Index<br>
><br>
> Hi,<br>
><br>
> Couldn't the default implementation of the reader base class implement an<br>
> index based access using a name / index hashtable?<br>
> That way index based access would be about as slow as name based access in<br>
> the default cases and in providers taht override this index based behavior<br>
> the access would be faster. It also would not put a burden on the client<br>
> code while not loosing any performance in either case.<br>
><br>
> Cheers,<br>
> Carsten<br>
> ________________________________________<br>
> From: <a href="mailto:fdo-internals-bounces@lists.osgeo.org">fdo-internals-bounces@lists.osgeo.org</a>
[fdo-internals-<br>
> <a href="mailto:bounces@lists.osgeo.org">bounces@lists.osgeo.org</a>] On
Behalf Of Klain Qin [<a href="mailto:klain.qin@autodesk.com">klain.qin@autodesk.com</a>]<br>
> Sent: Tuesday, September 15, 2009 9:34 PM<br>
> To: FDO Internals Mail List<br>
> Subject: [fdo-internals] RE: MOTION: FDO RFC 34 - FDO Reader Access By
Index<br>
><br>
> To fix all of the providers internally would be hard and involve much
work.<br>
> One example is: there are several providers like sqllite/rdbms which have<br>
> delay loading readers in some cases meaning the first property being<br>
> accessed will be first cached for class definition. There are other<br>
> complexities to ensure the consistency. So to provide an API like<br>
> GetPropertyIndex() would be easier for the users to use the new API<br>
> conveniently and correctly. The only concern is, as you mentioned, the<br>
> client codes have to keep a property name->index map by themselves. But<br>
> still providing this new API will be the easiest and least efforts at this<br>
> time.<br>
><br>
> Klain<br>
><br>
> From: <a href="mailto:fdo-internals-bounces@lists.osgeo.org">fdo-internals-bounces@lists.osgeo.org</a>
[mailto:<a href="mailto:fdo-internals-">fdo-internals-</a><br>
> <a href="mailto:bounces@lists.osgeo.org">bounces@lists.osgeo.org</a>] On
Behalf Of Traian Stanev<br>
> Sent: Tuesday, September 15, 2009 10:25 PM<br>
> To: FDO Internals Mail List<br>
> Subject: [fdo-internals] RE: MOTION: FDO RFC 34 - FDO Reader Access By
Index<br>
><br>
><br>
> How hard would it be to fix the providers internally so that the index of<br>
> the properties in the collection returned with GetClassDefinition<br>
> corresponds to the index needed for getting the property by index? I
suspect<br>
> it is not too hard since it would involve the same amount of work as<br>
> implementing this new GetPropertyIndex API, but will not add new API that<br>
> one has to call before getting the properties by index.<br>
><br>
><br>
> Traian<br>
><br>
><br>
> From: <a href="mailto:fdo-internals-bounces@lists.osgeo.org">fdo-internals-bounces@lists.osgeo.org</a>
[mailto:<a href="mailto:fdo-internals-">fdo-internals-</a><br>
> <a href="mailto:bounces@lists.osgeo.org">bounces@lists.osgeo.org</a>] On
Behalf Of Klain Qin<br>
> Sent: Monday, September 14, 2009 11:02 PM<br>
> To: FDO Internals Mail List<br>
> Subject: [fdo-internals] RE: MOTION: FDO RFC 34 - FDO Reader Access By
Index<br>
><br>
> Hi all,<br>
><br>
> While this RFC is being voted, I've updated it again in order to use
access<br>
> by index API more efficiently and correctly.<br>
><br>
> Previously in order to use access by index functions for FdoIFeatureReader<br>
> or FdoIDataReader, the API users will have to know beforehand how index is<br>
> mapping to property name. And mapping is different for different provider<br>
> implementations like SqlLite/SDF and RDBMS. E.g. with the same FDO schema<br>
> definition, SqlLite and RDBMS will arrange the property order returned
from<br>
> GetClassDefinition() differently:<br>
><br>
><br>
> a. If you don't set selected property names be
returned from an<br>
> FdoISelect command<br>
><br>
><br>
><br>
> SqlLite provider will arrange the properties in the order: Identity
property<br>
> -> Geometry property -> the left will be arranged in the order of
how they<br>
> are added into the class definition, like ID -> geometry ->
datetime-><br>
> double<br>
><br>
> For RDBMS provider the order is: identity property -> the left is
ordered by<br>
> the first character of the property name like ID -> datetime->
double -><br>
> geometry<br>
><br>
><br>
><br>
> b. If you do set selected property names to be
returned from an<br>
> FdoISelect command<br>
><br>
><br>
><br>
> SqlLite provider will respect the order of how they are added to selected<br>
> properties.<br>
><br>
> SDF provider will respect the order of corresponding properties defined in<br>
> the original class definition(without setting selected properties)<br>
><br>
> So to resolve this inconvenience, RFC 34 is updated again to add another<br>
> function for getting the index of a specific property name. Now both of
the<br>
> property name and index related functions are moved to FdoIReader as they<br>
> are needed for both FdoIFeatureReader and FdoIDataReader.<br>
> FdoString* GetPropertyName(FdoInt32 index);<br>
> FdoInt32 GetPropertyIndex(FdoString* propertyName);<br>
> Can you take a look again at this RFC?<br>
><br>
> <a href="http://trac.osgeo.org/fdo/wiki/FDORfc34" target="_blank">http://trac.osgeo.org/fdo/wiki/FDORfc34</a><br>
><br>
> Thanks,<br>
> Klain<br>
><br>
> From: <a href="mailto:fdo-internals-bounces@lists.osgeo.org">fdo-internals-bounces@lists.osgeo.org</a>
[mailto:<a href="mailto:fdo-internals-">fdo-internals-</a><br>
> <a href="mailto:bounces@lists.osgeo.org">bounces@lists.osgeo.org</a>] On
Behalf Of Greg Boone<br>
> Sent: Monday, September 14, 2009 11:33 PM<br>
> To: FDO Internals Mail List<br>
> Subject: [fdo-internals] MOTION: FDO RFC 34 - FDO Reader Access By Index<br>
><br>
> Hi all,<br>
><br>
> There were no further comments on RFC 34:<br>
> <a href="http://trac.osgeo.org/fdo/wiki/FDORfc34" target="_blank">http://trac.osgeo.org/fdo/wiki/FDORfc34</a>
- FDO Reader Access By Index.<br>
><br>
> I would like to motion a vote to accept this RFC.<br>
><br>
> Thanks,<br>
> Greg.<br>
><br>
><br>
><br>
> From: <a href="mailto:fdo-internals-bounces@lists.osgeo.org">fdo-internals-bounces@lists.osgeo.org</a>
[mailto:<a href="mailto:fdo-internals-">fdo-internals-</a><br>
> <a href="mailto:bounces@lists.osgeo.org">bounces@lists.osgeo.org</a>] On
Behalf Of Greg Boone<br>
> Sent: Wednesday, September 09, 2009 12:41 PM<br>
> To: FDO Internals Mail List<br>
> Subject: [fdo-internals] RE: FDO RFC 34 - FDO Reader Access By Index<br>
><br>
> Hi All,<br>
><br>
> FDO RFC 34 - Access By Index: <a
href="http://trac.osgeo.org/fdo/wiki/FDORfc34" target="_blank">http://trac.osgeo.org/fdo/wiki/FDORfc34</a>
has<br>
> been updated and is ready for a secondary review.<br>
><br>
> Please refer to the section labeled: "Provider Implementation"<br>
><br>
> Please respond with comments by end of day, Friday September 11.<br>
><br>
> Greg<br>
><br>
> From: <a href="mailto:fdo-internals-bounces@lists.osgeo.org">fdo-internals-bounces@lists.osgeo.org</a>
[mailto:<a href="mailto:fdo-internals-">fdo-internals-</a><br>
> <a href="mailto:bounces@lists.osgeo.org">bounces@lists.osgeo.org</a>] On
Behalf Of Greg Boone<br>
> Sent: Thursday, August 06, 2009 9:39 AM<br>
> To: FDO Internals Mail List<br>
> Subject: [fdo-internals] FDO RFC 34 - FDO Reader Access By Index<br>
><br>
> Hi All,<br>
><br>
> FDO RFC 34, <a href="http://trac.osgeo.org/fdo/wiki/FDORfc34"
target="_blank">http://trac.osgeo.org/fdo/wiki/FDORfc34</a>, is ready for
review.<br>
><br>
> Please review and respond with comments.<br>
><br>
> Greg<br>
><br>
><br>
><br>
><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><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><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><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>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</div>
</body>
</html>