[fdo-internals] RFC 20 for review

[Thomas Knoell]

Hi Harris,

Sorry for the late response.

Please see inline.

Thanks

  Thomas


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 2:53 PM
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.
[tok] No, I don't think that the FDO version would increase because of the addition of a new capability.


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.
[tok] The proposed functions in the class FdoICapability are specific to a return type. Therefore, - for example - all capabilities that return a boolean value are covered by the GetBooleanCapability interface. If an interface is called with a capability that is not associated with the return type handled by that interface, the "isUnknown" flag is set and a default value returned. The flag would also have been set if the capability is not yet supported by a provider.

As for new capabilities, I believe that Orest's mail clarifies this. The idea is that an agreement has been reached to add a new capability. With this agreement the capability and its return type are defined and it is expected that if a provider implements the support for this capability, it would be processed by the corresponding interface defined by the class FdoICapability.


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 ?
[tok] As mentioned, the addition of a new capability would require an agreement that the capability is needed. This agreement would also have to include the capability identifier that any provider may use to implement the support for it. This would also prevent duplication of capability identifiers.

Again, I believe Orest's mail points out the essential of what we want to achieve: add a capability without having to change all providers at once to support the new capability. Also, in some cases, a provider may not support that new capability and the then default handling of the FdoICapability class implementation would be sufficient (basically, there is no need to add a new interface to the provider that indicates that the capability is not supported).


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/20080710/cdd1dcbe/attachment-0001.html