[fdo-internals] RFC 20 for review

[Dan Stoica]

Hi,

Jason, it is not a general desire, the current state of things is not new and is really painful. Yet another example: SqlServer 2008 requires geodetic polygons in strict CCW orientation. On the other hand, SHP require CW orientation. We also need to address it -now-- for everybody's benefit. Other benefits can follow, e.g. we could enhance CreatePolygon() to take an optional parameter to control the orientation.


*         It's too easy to break the concept of generic capabilities.

In my opinion we are done with generic capabilities. The problem at hand is that it appears to be very difficult to address specific limitations with the current approach. And not being able to add quickly a capability means the user will be forced to do something against the FDO philosophy: check the provider name etc. :(

Thanks,
Dan.

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 2:35 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 20 for review

Hi Jason,

Orest outlines a use case (geometry curve types) where this approach would be helpful. Again, the main benefit of this approach is that once a new capability has been approved by the PSG, there is no need to add a new capability interface to FDO and hence force all providers to be updated immediately. Eventually, it should be done, but with the new approach it is up to the provider developer to schedule the work. FDO would still be fine and working until then. This is a bit more flexible.

Thomas


From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Thursday, July 17, 2008 12:24 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 20 for review

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/20080718/8ac25a5d/attachment-0001.html