[prev in list] [next in list] [prev in thread] [next in thread]
List: fdo-internals
Subject: RE: [fdo-internals] RFC 20 for review
From: Greg Boone <greg.boone () autodesk ! com>
Date: 2008-07-18 18:22:59
Message-ID: C58680A9E35DCE45A8F1A3CA451C4DA32A51783989 () ADSK-NAMSG-01 ! MGDADSK ! autodesk ! com
[Download RAW message or body]
Hi Harris,
As I see it, there has been some uncertainty in the community surrounding t=
he adoption of this RFC. While members are not against it, they are not nec=
essarily for it either. While I do believe the RFC will solve a problem tha=
t provider developers face, it does not mean that there are no alternatives=
or that it is imperative that the community resolve this issue immediately=
. Ultimately, I do want to do what is best for the API in long run, so that=
it evolves in the right direction.
I would encourage the community to take an additional week to think about t=
he pros and cons of the RFC. In this time, take the time to consider what t=
hey think is appropriate from an API perspective. If we still cannot reach =
consensus, then I feel that we would have to reconsider adopting the RFC. W=
e would have to defer the issue until a time when a proposal can be develop=
ed that can be fully endorsed.
Thanks,
Greg
From: fdo-internals-bounces@lists.osgeo.org [mailto:fdo-internals-bounces@l=
ists.osgeo.org] On Behalf Of Thomas Knoell
Sent: Thursday, July 17, 2008 2:55 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 20 for review
Hi Haris,
How much time would you need?
Thanks
Thomas
From: fdo-internals-bounces@lists.osgeo.org [mailto:fdo-internals-bounces@l=
ists.osgeo.org] On Behalf Of Haris Kurtagic
Sent: Thursday, July 17, 2008 2:58 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 20 for review
Hi Tomas,
I would suggest to prolonge deadline for this RFC ?
Haris
From: fdo-internals-bounces@lists.osgeo.org [mailto:fdo-internals-bounces@l=
ists.osgeo.org] On Behalf Of Thomas Knoell
Sent: Thursday, July 17, 2008 5:58 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 20 for review
Hi,
This is a reminder that the deadline for comments on RFC 20 is end-of-day t=
omorrow. I would also appreciate comments on Orest's summary below.
Thanks
Thomas
From: fdo-internals-bounces@lists.osgeo.org [mailto:fdo-internals-bounces@l=
ists.osgeo.org] On Behalf Of Orest Halustchak
Sent: Tuesday, July 15, 2008 9:34 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 20 for review
Hi,
I haven't heard any response - do folks think it's worth pursuing this. If =
it's worthwhile in principle but need to fix the details or not worthwhile?
Thanks,
Orest.
From: fdo-internals-bounces@lists.osgeo.org [mailto:fdo-internals-bounces@l=
ists.osgeo.org] On Behalf Of Orest Halustchak
Sent: Thursday, July 10, 2008 1:27 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 20 for review
Hi,
Getting back to the general discussion, and trying to step back a bit, ther=
e are definitely trade-offs here.
Pros:
* Easier to define new capabilities: Instead of having a new functi=
on every time we want to advertise a new capability, we can use a generic f=
unction and not have to change the fdo api.
* Providers can be updated over time rather than all having to be r=
ecompiled with a new version of the fdo api.
* A small set of functions to call to discover all of a provider's =
capabilities.
Cons:
* Too easy for providers to start defining their own very provider =
specific capabilities. Perhaps for the osgeo providers we can control this =
because we should still have RFC process, but we can't control commercial p=
roviders. This is the concern that a few of you have raised. It's too easy =
to break the concept of generic capabilities.
* Developer has to know the return type to use the correct generic =
function to get a capability value.
Maybe there are more pros and cons, but these are some of the main ones.
Also, this mostly helps cases where we need to advertise a new capability t=
hat doesn't require other api changes. For instance, if we add a whole set =
of new functions around network handling, we are changing the api anyway, s=
o the benefits aren't really there as much. But, if we discover that for ex=
isting functions, we're hitting an issue with different behavior that shoul=
d be advertised, e.g. providers A, B, and C support geometry curve types, b=
ut providers B and C only support them for non-lat/long systems, we're not =
adding new functions, just a more detailed capabilities response. Once the =
PSC agrees on the capability, it can be added without a new version of the =
fdo api. The current approach would need to define a new function somewhere=
which implies a new fdo api version - recompile all providers, etc.
If we feel that the benefit does not outweigh the costs, then we shouldn't =
bother with it.
I hope this helps clarify things.
Thanks,
Orest.
From: fdo-internals-bounces@lists.osgeo.org [mailto:fdo-internals-bounces@l=
ists.osgeo.org] On Behalf Of Haris Kurtagic
Sent: Thursday, July 10, 2008 12:57 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 20 for review
Yes, I was trying to imagine how versions would work.
Thanks Robert :)
Haris
From: fdo-internals-bounces@lists.osgeo.org [mailto:fdo-internals-bounces@l=
ists.osgeo.org] On Behalf Of Robert Fortin
Sent: Thursday, July 10, 2008 5:09 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 20 for review
Without speaking for Harris, I think Haris is discussing the impact of the =
suggested API vs the provider/FDO version number when a new capability is a=
dded at FDO level. The new API would not require the a FDO version upgrade=
which is now the case everytime we add a single new capability.
RF
From: fdo-internals-bounces@lists.osgeo.org [mailto:fdo-internals-bounces@l=
ists.osgeo.org] On Behalf Of Dan Stoica
Sent: Thursday, July 10, 2008 9:56 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 20 for review
Hi,
[Haris] We would say it is FDO 3.4.1 because one provider have new capabili=
ty ? I think FDO capabilities "belongs" to FDO not to providers.
I'm confused. On one hand you suggest that we shouldn't rebuild FDO when on=
e provider is adding a new capability. On the other hand, I cannot see how=
a new capability "belongs" to FDO without rebuilding FDO.
Could you please elaborate?
Thanks,
Dan.
From: fdo-internals-bounces@lists.osgeo.org [mailto:fdo-internals-bounces@l=
ists.osgeo.org] On Behalf Of Orest Halustchak
Sent: Wednesday, July 09, 2008 3:56 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 20 for review
Hi,
I agree that we don't want provider specific capabilities, that capabilitie=
s need to be specified in a generic way. I agree with Haris' statement that=
capabilities belong to fdo and not to providers.
But, is there a way to simplify the process of adding new capabilities (aft=
er 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, sm=
aller, set of functions, new capabilities can be defined without changing t=
he api. Providers can be updated over time as opposed to requiring all prov=
iders to be updated right away. It seems that a side effect of trying to ac=
hieve this goal opens the possibility of individual provider specific capab=
ilities, but that isn't the intention. The intention is to have some robust=
ness so that if a newly defined capability is handled by one provider, usin=
g another provider that hasn't been updated yet won't break the application=
. An application can start taking advantage of a new capability without wai=
ting for all providers to be updated to the new api.
There was an email thread a while ago I believe expressing concern about th=
e complexity of all the capabilities functions and having to add new functi=
ons each time. It seems that if we want to do this, we should try to deal w=
ith it soon or decide that we'll just live with the current approach. There=
are pros/cons to each. Are there other approaches/ideas?
Thanks,
Orest.
From: fdo-internals-bounces@lists.osgeo.org [mailto:fdo-internals-bounces@l=
ists.osgeo.org] On Behalf Of Jason Birch
Sent: Wednesday, July 09, 2008 3:34 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 20 for review
I have to say that this was also my initial impression of the RFC, and to s=
ome extent the RDBMS vs file distinction in RFC23. They serve to reduce th=
e homogeneity of FDO, which in turn makes building applications based on FD=
O more difficult.
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. If this does go through, it w=
ould be important to make it clear that adding a new capability to a provid=
er would not be excluded from the RFC process.
The more divergent the individual providers become, the less easy it is to =
write an application that works with all providers. Reducing the cost of m=
aintaining the core library at a consistent level results in this cost bein=
g passed along exponentially to all clients that have to manage inconsisten=
cies between the providers. I understand that there is some pain keeping =
the providers in sync, but that's the price of an abstract framework. Mayb=
e this is not a good way of looking at it, but my feeling is that ff certai=
n providers can't be upgraded with new functionality, then they will just g=
et left behind until the community recognises the need to upgrade them to t=
he latest version of FDO and applies resources to get them caught up.
In my view, new capabilities should only be added when they are absolutely =
required and after serious consideration. In some ways, this cost is a goo=
d thing, as it slows the rate of change in the framework.
Jason
From: fdo-internals-bounces@lists.osgeo.org [mailto:fdo-internals-bounces@l=
ists.osgeo.org] On Behalf Of Haris Kurtagic
Sent: Wednesday, July 09, 2008 11:53
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 20 for review
Hi Tomass,
thanks for answers.
I am very uncomfortable with this RFC. Perhaps I don't understand it well e=
nough so I will ask many questions and try to understand motivation for it.
In your previous answer you said that motivation is to not rebuild FDO and =
providers because of one provider change.
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.
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.
I think unified and clear access to different data stores is far more impor=
tant than "fast" adding of new capability for one particular provider.
I see this RFC as a path to start to write applications which are tied to p=
articular providers.
I would like to understand use case of it and would try to ask with example=
.
If I see it correctly use case of this would be that we have application bu=
ild 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 applicatio=
n with same "old" FDO 3.4 but with new version of provider .
Does this implies that we could have different flavors of FDO 3.4 or it wou=
ld 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 ?
I think FDO capabilities "belongs" to FDO not to providers.
As of discussion about new capabilities enumerators not coded anywhere or u=
se of strings. I also feel like it is wrong.
How we would share those enumerations or strings between providers ? It cou=
ld end up that because some new capability is not supported in all provider=
s 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.
As of error handling: same result ("isUnknown" to true ) would be for non e=
xisting capability as well as for wrong type of it ?
Again sounds like we could end up with different type reported from differe=
nt providers for same capability.
When writing FDO client application It would be wrong if we would need to c=
heck at different lists to find codes for same capability and to check it a=
gainst all providers.
You mentioned : "certain unique mechanism in place to avoid duplication". =
This is yet to decide ?
Sorry if I am little hard or long but this RFC seems very important to me.
Haris
From: fdo-internals-bounces@lists.osgeo.org [mailto:fdo-internals-bounces@l=
ists.osgeo.org] On Behalf Of Thomas Knoell
Sent: Wednesday, July 09, 2008 7:20 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 20 for review
Hi Harris,
Thanks for the comments.
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 tha=
t 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 changi=
ng FDO. As a result, only the provider that wants to support the new capabi=
lity needs to implement the support.
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 a=
n Int32 - the function would set the flag "isUnknown" 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.
Thanks
Thomas
From: fdo-internals-bounces@lists.osgeo.org [mailto:fdo-internals-bounces@l=
ists.osgeo.org] On Behalf Of Haris Kurtagic
Sent: Tuesday, July 08, 2008 7:45 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 20 for review
I think this is much more complicated way of exposing capabilities rather t=
han like it says in RFC simplifying.
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 b=
e used anyhow .
I can't see reasons when application which is build for use with one versio=
n of FDO libraries will use older providers.
Also Isn't it going to be a problem when application is linked with one ver=
sion of FDO core libraries and provider is like build with another. With cu=
rrent dll naming it is not possible I think ?
I couldn't find in RFC error handling for case when function of wrong type =
of capability is executed for existing capability ( e.g. Call GetBooleanCap=
ability for Int32 ) ?
Haris
From: fdo-internals-bounces@lists.osgeo.org [mailto:fdo-internals-bounces@l=
ists.osgeo.org] On Behalf Of Thomas Knoell
Sent: Tuesday, July 08, 2008 11:38 PM
To: fdo-internals@lists.osgeo.org
Subject: [fdo-internals] RFC 20 for review
Hi,
RFC 20 (http://trac.osgeo.org/fdo/wiki/FDORfc20) has been posted. It propos=
es 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 18th. It is intended to request a vote=
on the RFC afterwards.
Thanks
Thomas
[Attachment #3 (text/html)]
<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: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: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;}
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:10.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Times New Roman","serif";
color:windowtext;
font-weight:normal;
font-style:normal;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Times New Roman","serif";
color:#1F497D;
font-weight:normal;
font-style:normal;}
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;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle24
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle25
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#993366;}
span.EmailStyle26
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle27
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle28
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle29
{mso-style-type:personal;
font-family:"Times New Roman","serif";
color:#1F497D;
font-weight:normal;
font-style:normal;}
span.EmailStyle30
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle31
{mso-style-type:personal;
font-family:"Times New Roman","serif";
color:#1F497D;
font-weight:normal;
font-style:normal;}
span.EmailStyle32
{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:545068297;
mso-list-type:hybrid;
mso-list-template-ids:1906889200 67698689 67698691 67698693 67698689 67698691 \
67698693 67698689 67698691 67698693;} @list l0:level1
{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;}
@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;}
@list l1
{mso-list-id:1193307383;
mso-list-type:hybrid;
mso-list-template-ids:667215760 67698689 67698691 67698693 67698689 67698691 \
67698693 67698689 67698691 67698693;} @list l1:level1
{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;}
@list l1:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1: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'>Hi Harris,<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'>As I see it, there has been some uncertainty in the community \
surrounding the adoption of this RFC. While members are not against it, they are not
necessarily for it either. While I do believe the RFC will solve a problem that
provider developers face, it does not mean that there are no alternatives or
that it is imperative that the community resolve this issue immediately. Ultimately,
I do want to do what is best for the API in long run, so that it evolves in the
right direction. <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 would encourage the community to take an additional week to
think about the pros and cons of the RFC. In this time, take the time to consider
what they think is appropriate from an API perspective. If we still cannot
reach consensus, then I feel that we would have to reconsider adopting the RFC.
We would have to defer the issue until a time when a proposal can be developed that
can be fully endorsed.<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'>Greg <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-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> Thursday, July 17, 2008 2:55 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> </o:p></p>
<p class=MsoNormal><span style='color:#1F497D'>Hi Haris,<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>How much time would you \
need?<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>Thanks<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'> Thomas<o:p></o:p></span></p>
<p class=MsoNormal><span style='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-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> Thursday, July 17, 2008 2:58 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> </o:p></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Hi Tomas,<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 would suggest to prolonge deadline for this RFC \
?<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'>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>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<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> Thursday, July 17, 2008 5:58 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> </o:p></p>
<p class=MsoNormal><span style='color:#1F497D'>Hi,<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>This is a reminder that the
deadline for comments on RFC 20 is end-of-day tomorrow. I would also appreciate
comments on Orest’s summary below.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>Thanks<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'> Thomas<o:p></o:p></span></p>
<p class=MsoNormal><span style='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-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> Tuesday, July 15, 2008 9:34 AM<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> </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> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I haven’t heard any response – do folks think
it’s worth pursuing this. If it’s worthwhile in principle but need
to fix the details or not worthwhile?<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>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<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> Thursday, July 10, 2008 1:27 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> </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> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Getting back to the general discussion, and trying to step back
a bit, there are definitely trade-offs here.<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'>Pros:<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'>Easier to \
define new capabilities: Instead of having a new function every time we want to \
advertise a new capability, we can use a generic function and not have to change the \
fdo api.<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'>Providers \
can be updated over time rather than all having to be recompiled with a new version \
of the fdo api.<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'>A small \
set of functions to call to discover all of a provider’s \
capabilities.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Cons:<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l1 level1 lfo4'><![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'>Too easy \
for providers to start defining their own very provider specific capabilities. \
Perhaps for the osgeo providers we can control this because we should still have RFC \
process, but we can’t control commercial providers. This is the concern that a \
few of you have raised. It’s too easy to break the concept of generic \
capabilities.<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l1 level1 lfo4'><![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'>Developer \
has to know the return type to use the correct generic function to get a capability \
value.<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'>Maybe there are more pros and cons, but these are some of the
main ones.<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'>Also, this mostly helps cases where we need to advertise a new \
capability that doesn’t require other api changes. For instance, if we add a \
whole set of new functions around network handling, we are changing the api anyway,
so the benefits aren’t really there as much. But, if we discover that for
existing functions, we’re hitting an issue with different behavior that
should be advertised, e.g. providers A, B, and C support geometry curve types,
but providers B and C only support them for non-lat/long systems, we’re
not adding new functions, just a more detailed capabilities response. Once the
PSC agrees on the capability, it can be added without a new version of the fdo
api. The current approach would need to define a new function somewhere which
implies a new fdo api version – recompile all providers, \
etc.<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'>If we feel that the benefit does not outweigh the costs, then we
shouldn’t bother with 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> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I hope this helps clarify things.<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>
<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-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> Thursday, July 10, 2008 12:57 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> </o:p></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Yes, I was trying to imagine how versions would \
work.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Thanks Robert :)<o:p></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> </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-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>Robert Fortin<br>
<b>Sent:</b> Thursday, July 10, 2008 5:09 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> </o:p></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#993366'>Without speaking for Harris, I think Haris is discussing the impact
of the suggested API vs the provider/FDO version number when a new capability
is added at FDO level. The new API would not require the a FDO version
upgrade which is now the case everytime we add a single new \
capability.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#993366'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#993366'>RF<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#993366'><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-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>Dan Stoica<br> \
<b>Sent:</b> Thursday, July 10, 2008 9:56 AM<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> </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> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>[Haris] We would say it is FDO 3.4.1 because one provider have
new capability ? I think FDO capabilities “belongs” 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> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I’m confused. On one hand you suggest that we
shouldn’t rebuild FDO when one provider is adding a new capability.
On the other hand, I cannot see how a new capability “belongs” to
FDO without rebuilding FDO.<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'>Could you please elaborate?<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'>Dan.<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>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<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 3: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> </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> </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’t want provider specific capabilities,
that capabilities need to be specified in a generic way. I agree with
Haris’ 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> </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’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’t been updated yet won’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> </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’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> </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>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<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> </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. 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> </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. 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> </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. 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. I understand that there is some pain keeping the providers in \
sync, but that’s the price of an abstract framework. Maybe this is not a \
good way of looking at it, but my feeling is that ff certain providers can’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> </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. 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> </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> </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-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> </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’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> </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> </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 “fast” 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> </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 “old” 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 “belongs” 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> </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> </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>"isUnknown"
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 : “</span>certain unique mechanism in place
to avoid duplication”. 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> </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> </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> </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-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> </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> </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> </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> </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 "isUnknown" 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> </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> </o:p></p>
<p class=MsoNormal style='text-autospace:none'> Thomas<o:p></o:p></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='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-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> </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> </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’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’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> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I couldn’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> </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> </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-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> </o:p></p>
<p class=MsoNormal>Hi,<o:p></o:p></p>
<p class=MsoNormal><o:p> </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> It
is intended to request a vote on the RFC afterwards.<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>Thanks<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal> Thomas<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</body>
</html>
_______________________________________________
fdo-internals mailing list
fdo-internals@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
--===============1547950743==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic