[fdo-internals] RFC 20 for review

[Dan Stoica]

Thomas, Robert,


a.       FdoCommandType_FirstProviderCommand - the idea is good, but its usage is wrong since its value changes when you add a new FDO command.



b.      "different names for the same capability in different providers"  - a new capability is approved by an RFC along with its name. I guess it would be unlikely to have a second RFC approved for the same capability but with a different name.
In contrast, by using  numbers we can get different capabilities for the same number in different providers (Therefore, seems that FdoCapabilityType.h is mandatory to have)


c.       "cost involved with processing it (string comparison)" - I need some statistics in order to be convinced.

Dan.

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

Dan,

The approach taken is similar to the CreateCommand function.  Although it has an enumeration for the commands, it actually use a Int32 in order to account for the possibility of custom commands.  Same here: the enumaration is the standard; capability # outside the range of the enumaration are custom to a provider.  This remind me that should have a limit for custom capability just like we have a limit for custom command (see FdoCommandType_FirstProviderCommand).

RF


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

Dan,

I disagree with the suggestion that each provider maintains its own list of capabilities. That would mean that an application has to have provider specific capability handling and that is not something we should need. Also, if each provider maintains its list, then there is the chance that there are different names for e same capability in different providers. That, again, cannot be a goal.

We discussed using strings versus numbers before. As mentioned before, the main reason why numbers were selected is the cost involved with processing it (string comparison). With numbers, you can always define a meaningful representative name for a capability. That has the same affect.

Thanks

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

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