[fdo-internals] RFC 20 for review

[Jason Birch]

As a non-developer I guess I don't have a feeling for the amount of pain
involved in the current state (and don't entirely understand the need to
decouple FDO's API from the providers), so can't really make a call on
whether this change is worth it.  Was there a specific case that caused
this RFC to be created, or is this just a general desire?

 

As I mentioned before, I have some serious reservations about anything
that makes it easier for specific providers to diverge from generic
functionality, but if others feel that the cost/benefit is there, then
I'll accept that decision.

 

Jason

 

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 08:58
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.

 

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