[fdo-internals] RFC 20 for review

Thu Jul 17 14:58:19 EDT 2008

Hi Tomas,

I would suggest to prolonge deadline for this RFC ?

Haris

From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.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 tomorrow. I would also appreciate comments on Orest's summary
below.

Thanks

  Thomas

From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.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 at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.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,
there are definitely trade-offs here.

Pros:

*         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.

*         Providers can be updated over time rather than all having to
be recompiled 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 providers. 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 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.

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 at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.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 at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.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 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.

RF

From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.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
capability ? 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
one 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 at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.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
capabilities 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
(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.

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?

Thanks,

Orest.

From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.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 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.

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.

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.

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.

Jason

From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.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 enough 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
important 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 particular 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
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 .

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 ?

I think FDO capabilities "belongs" to FDO not to providers. 

As of discussion about new capabilities enumerators not coded anywhere
or use of strings. I also feel like it is wrong.

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.

As of error handling: same result ("isUnknown" to true ) would be for
non existing capability as well as for wrong type of it ?

Again sounds like we could end up with different type reported from
different providers for same capability.

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.

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 at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.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 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.

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.

Thanks

  Thomas

From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.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 than 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 be used anyhow .

I can't see reasons when application which is build for use with one
version of FDO libraries will use older providers. 

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 ?

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
GetBooleanCapability for Int32 ) ?

Haris

From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Thomas
Knoell
Sent: Tuesday, July 08, 2008 11:38 PM
To: fdo-internals at lists.osgeo.org
Subject: [fdo-internals] RFC 20 for review

Hi,

RFC 20 (http://trac.osgeo.org/fdo/wiki/FDORfc20) 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 18th.  It is
intended to request a vote on the RFC afterwards.

Thanks

  Thomas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20080717/a4d1c5b9/attachment-0001.html