[fdo-internals] RFC 20 for review

[Dan Stoica]

Thomas,

I understand now. Not sure you captured this explanations in your document.

However, I think using numbers is wrong. How would the user know them?

Instead, I would suggest the following:

-          Each provider maintains its list of capability names - this breaks the dependency provider <-> FDO. There is no need to be the same across providers

-           FdoICapability  methods should take names instead of numbers - so you can add a new capability and have a meaningful way to access it

-          FdoIConnection should have another method GetCapabilityNames() - so the user can know the names.

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 10, 2008 12:26 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 20 for review

Hi Dan,

The enumeration FdoICapabilityType represents a snapshot of all capabilities that are supported at the time it is implemented. It lists capability identifiers for each of the supported capabilities that can be used and provides an easy access to the identifier list. Those identifiers are necessary to retrieve a capability value. The identifiers will also be documented where the description also includes the return type of the capability. All this information is required by the user to select the correct interface to retrieve a capability value. Theoretically, we can even go ahead and remove the enumeration, it would not make a difference.

If a new capability is added, that capability together with its return type would need to be documented with all other capability identifiers to ensure that a provider wanting to support it has all the information to access it. Again, there is no need to add it to the enumeration (assuming we keep it around). We may decide to update the enumeration if we do a update to the FDO core that results in a version upgrade to reflect the snapshot of the capabilities available at that time.

Thomas


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

Thomas,

If that Int32 is not an FdoCapabilityType - then what is it?

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 10, 2008 12:02 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 20 for review

Hi Dan,

Adding a new capability does not require an update of the enumeration FdoCapabilityType.h. If you look at the interfaces, you see that a capability is identified by an Int32 number, not by a parameter of the enumeration type. So you can add new capabilities without changing the FDO version.

Thomas


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

"The new API would not require the a FDO version upgrade"

Depends. Unless the new enum is added at the end of FdoCapabilityType.h you have to rebuild your application. And this accounts for a version upgrade.

BTW, I think the opposite: the capabilities belong to the providers. Because "capabilities" is another way to talk about "limitations" which are provider specific.

Dan.

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