<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: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:D="DAV:" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" 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:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" 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:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:Z="urn:schemas-microsoft-com:" 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:0cm;
        margin-bottom:.0001pt;
        font-size:10.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;}
span.EmailStyle17
        {mso-style-type:personal;
        font-family:"Times New Roman","serif";
        color:windowtext;
        font-weight:normal;
        font-style:normal;}
span.EmailStyle18
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.EmailStyle19
        {mso-style-type:personal;
        font-family:"Times New Roman","serif";
        color:#1F497D;
        font-weight:normal;
        font-style:normal;}
span.EmailStyle20
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.EmailStyle21
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.EmailStyle22
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.EmailStyle23
        {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:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
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 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>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I can&#8217;t see how this approach would help in robustness.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>My understanding is that when new capabilities appears in one particular
data store and if we want to build application for it, we need to build new
version of provider and build new version of application which will use that capability.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>As far as I can see profit would be that we would not need to
add code in every provider for new capabilities and build those providers.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>But I think that would be not profit in time but lost in FDO
concept. I think Jason gave us few very good points in his email.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>BTW:<o:p></o:p></span></p>

<p class=MsoNormal style='text-autospace:none'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>I think it is very good when
I try to compile provider against newer version of FDO and then I get </span><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>errors:
&nbsp;&#8220;</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>cannot instantiate abstract class due to following members:&#8221;<o:p></o:p></span></p>

<p class=MsoNormal style='text-autospace:none'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Makes me think about all those
new things, the ones I of&#8217;course forgot all about :)</span><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>

<p class=MsoNormal><b><span style='font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-family:"Tahoma","sans-serif"'>
fdo-internals-bounces@lists.osgeo.org
[mailto:fdo-internals-bounces@lists.osgeo.org] <b>On Behalf Of </b>Orest
Halustchak<br>
<b>Sent:</b> Wednesday, July 09, 2008 9:56 PM<br>
<b>To:</b> FDO Internals Mail List<br>
<b>Subject:</b> RE: [fdo-internals] RFC 20 for review<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Hi,<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I agree that we don&#8217;t want provider specific capabilities,
that capabilities need to be specified in a generic way. I agree with
Haris&#8217; statement that capabilities belong to fdo and not to providers.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>But, is there a way to simplify the process of adding new
capabilities (after agreeing that a new capability is needed and can be defined
in a generic way)? Instead of adding a new function each time, if we have a
generic, smaller, set of functions, new capabilities can be defined without
changing the api. Providers can be updated over time as opposed to requiring
all providers to be updated right away. It seems that a side effect of trying
to achieve this goal opens the possibility of individual provider specific
capabilities, but that isn&#8217;t the intention. The intention is to have some
robustness so that if a newly defined capability is handled by one provider,
using another provider that hasn&#8217;t been updated yet won&#8217;t break the
application. An application can start taking advantage of a new capability
without waiting for all providers to be updated to the new 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>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>There was an email thread a while ago I believe expressing
concern about the complexity of all the capabilities functions and having to
add new functions each time. It seems that if we want to do this, we should try
to deal with it soon or decide that we&#8217;ll just live with the current
approach. There are pros/cons to each. Are there other approaches/ideas?<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</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>&nbsp;</o:p></span></p>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>

<p class=MsoNormal><b><span style='font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='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, July 09, 2008 3:34 PM<br>
<b>To:</b> FDO Internals Mail List<br>
<b>Subject:</b> RE: [fdo-internals] RFC 20 for review<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal><span lang=EN-CA style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I have to say that this was also my initial impression of the
RFC, and to some extent the RDBMS vs file distinction in RFC23.&nbsp; They
serve to reduce the homogeneity of FDO, which in turn makes building
applications based on FDO more difficult.<o:p></o:p></span></p>

<p class=MsoNormal><span lang=EN-CA style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span lang=EN-CA style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I am concerned that this mechanism could be used to add new
capabilities to individual providers without considering whether these
capabilities would be better in a more generic form, or how applying them to a
single provider could affect other providers in the future.&nbsp; If this does
go through, it would be important to make it clear that adding a new capability
to a provider would not be excluded from the RFC process.<o:p></o:p></span></p>

<p class=MsoNormal><span lang=EN-CA style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span lang=EN-CA style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The more divergent the individual providers become, the less
easy it is to write an application that works with all providers.&nbsp;
Reducing the cost of maintaining the core library at a consistent level results
in this cost being passed along exponentially to all clients that have to
manage inconsistencies between the providers. &nbsp;&nbsp;I understand that
there is some pain keeping the providers in sync, but that&#8217;s the price of
an abstract framework.&nbsp; Maybe this is not a good way of looking at it, but
my feeling is that ff certain providers can&#8217;t be upgraded with new
functionality, then they will just get left behind until the community
recognises the need to upgrade them to the latest version of FDO and applies
resources to get them caught up.<o:p></o:p></span></p>

<p class=MsoNormal><span lang=EN-CA style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span lang=EN-CA style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>In my view, new capabilities should only be added when they are
absolutely required and after serious consideration.&nbsp; In some ways, this
cost is a good thing, as it slows the rate of change in the framework.<o:p></o:p></span></p>

<p class=MsoNormal><span lang=EN-CA style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span lang=EN-CA style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Jason<o:p></o:p></span></p>

<p class=MsoNormal><span lang=EN-CA style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>

<p class=MsoNormal><b><span style='font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='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> Wednesday, July 09, 2008 11:53<br>
<b>To:</b> FDO Internals Mail List<br>
<b>Subject:</b> RE: [fdo-internals] RFC 20 for review<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><span lang=EN-CA><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Hi Tomass,<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>thanks for answers.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I am very uncomfortable with this RFC. Perhaps I don&#8217;t
understand it well enough so I will ask many questions and try to understand
motivation for it.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>In your previous answer you said that motivation is to not
rebuild FDO and providers because of one provider change. <o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I think I understand your answer and motivation as it is written
in RFC but my concern was that doing that is not right thing. <o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>My main concern is that this RFC goes against one of the key
values of FDO: access different spatial data formats with one unified
interface.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I think unified and clear access to different data stores is far
more important than &#8220;fast&#8221; adding of new capability for one
particular provider.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I see this RFC as a path to start to write applications which
are tied to particular providers.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I would like to understand use case of it and would try to ask
with example.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>If I see it correctly use case of this would be that we have
application build against let say FDO 3.4. Then we would like to add new
capability to e.g. SDF provider and then use that new capability in new build
of application with same &#8220;old&#8221; FDO 3.4 but with new version of
provider .<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Does this implies that we could have different flavors of FDO
3.4 or it would be 3.4.1 but just no need to add capability to other providers?
We would say it is FDO 3.4.1 because one provider have new capability ?<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I think FDO capabilities &#8220;belongs&#8221; to FDO not to
providers. <o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>As of discussion about new capabilities enumerators not coded
anywhere or use of strings. I also feel like it is wrong.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>How we would share those enumerations or strings between
providers ? It could end up that because some new capability is not supported
in all providers at same time that it will have different number in different
providers ? Having some list (or few of them) of codes for capabilities sounds
very odd too me.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>As of error handling: same result (</span>&quot;isUnknown&quot;
to true<span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'> ) would be for non existing capability as well as for wrong
type of it ?<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Again sounds like we could end up with different type reported
from different providers for same capability.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>When writing FDO client application It would be wrong if we
would need to check at different lists to find codes for same capability and to
check it against all providers.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>You mentioned : &#8220;</span>certain unique mechanism in place
to avoid duplication&#8221;. &nbsp;This is yet to decide ?<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>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Sorry if I am little hard or long but this RFC seems very
important to me.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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>&nbsp;</o:p></span></p>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>

<p class=MsoNormal><b><span style='font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-family:"Tahoma","sans-serif"'> fdo-internals-bounces@lists.osgeo.org
[mailto:fdo-internals-bounces@lists.osgeo.org] <b>On Behalf Of </b>Thomas
Knoell<br>
<b>Sent:</b> Wednesday, July 09, 2008 7:20 PM<br>
<b>To:</b> FDO Internals Mail List<br>
<b>Subject:</b> RE: [fdo-internals] RFC 20 for review<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal style='text-autospace:none'>Hi Harris,<o:p></o:p></p>

<p class=MsoNormal style='text-autospace:none'><o:p>&nbsp;</o:p></p>

<p class=MsoNormal style='text-autospace:none'>Thanks for the comments.<o:p></o:p></p>

<p class=MsoNormal style='text-autospace:none'><o:p>&nbsp;</o:p></p>

<p class=MsoNormal style='text-autospace:none'>As for the motivation, currently
there is no way to add a new capability to FDO without the need to implement
that new capability in all providers that want to use the updated FDO code
base. The new interface concept provides the chance to actually do this as
capabilities can be added without changing FDO. As a result, only the provider
that wants to support the new capability needs to implement the support.<o:p></o:p></p>

<p class=MsoNormal style='text-autospace:none'><o:p>&nbsp;</o:p></p>

<p class=MsoNormal style='text-autospace:none'>As for the error handling, this
is documented in RFC 20. If a user calls a function - for example
GetBooleanCapability for a capability that returns an Int32 - the function
would set the flag &quot;isUnknown&quot; to true. It is up to the caller to
check this flag an react accordingly. For example, the caller could either use
a default value that is appropriate in this case or throw an exception. But
this is all up to the caller.<o:p></o:p></p>

<p class=MsoNormal style='text-autospace:none'><o:p>&nbsp;</o:p></p>

<p class=MsoNormal style='text-autospace:none'>Thanks<o:p></o:p></p>

<p class=MsoNormal style='text-autospace:none'><o:p>&nbsp;</o:p></p>

<p class=MsoNormal style='text-autospace:none'>&nbsp; Thomas<o:p></o:p></p>

<p class=MsoNormal><span style='color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>

<p class=MsoNormal><b><span style='font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='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> Tuesday, July 08, 2008 7:45 PM<br>
<b>To:</b> FDO Internals Mail List<br>
<b>Subject:</b> RE: [fdo-internals] RFC 20 for review<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I think this is much more complicated way of exposing
capabilities rather than like it says in RFC simplifying.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I am not sure about motivation for it. For example If
application is build with newer version of FDO core I would think that older
provider will not be used anyhow .<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I can&#8217;t see reasons when application which is build for
use with one version of FDO libraries will use older providers. <o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Also Isn&#8217;t it going to be a problem when application is
linked with one version of FDO core libraries and provider is like build with
another. With current dll naming it is not possible I think ?<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I couldn&#8217;t find in RFC error handling for case when
function of wrong type of capability is executed for existing capability ( e.g.
Call </span><span lang=EN style='color:black'>GetBooleanCapability for Int32 )
?</span><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>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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>&nbsp;</o:p></span></p>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>

<p class=MsoNormal><b><span style='font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-family:"Tahoma","sans-serif"'>
fdo-internals-bounces@lists.osgeo.org
[mailto:fdo-internals-bounces@lists.osgeo.org] <b>On Behalf Of </b>Thomas
Knoell<br>
<b>Sent:</b> Tuesday, July 08, 2008 11:38 PM<br>
<b>To:</b> fdo-internals@lists.osgeo.org<br>
<b>Subject:</b> [fdo-internals] RFC 20 for review<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>Hi,<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>RFC 20 (<a href="http://trac.osgeo.org/fdo/wiki/FDORfc20">http://trac.osgeo.org/fdo/wiki/FDORfc20</a>)
has been posted. It proposes a simplification of the FDO capability interfaces.
Please review the RFC and let me know of any questions and suggestions you may
have. The review deadline is set for end of day July 18<sup>th. </sup>&nbsp;It
is intended to request a vote on the RFC afterwards.<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>Thanks<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp; Thomas<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

</body>

</html>