[fdo-dev] Classes and properties in SHP providers

[Dan Stoica]

I believe the number of capabilities will just keep growing. Rationale:
it is absurd to think otherwise :-).

Now, I believe there was a better method to support capabilities:
instead of "SuportsThat()" methods we could have just one method
"Supports( that )" on the connection, where "that" is an enum. Some
advantages:
- way less methods on the interfaces
- makes the maintance less painful (right now we need to touch ALL
providers, just to say "not supported").

Just an idea...

Dan. 

-----Original Message-----
From: Traian Stanev 
Sent: Wednesday, November 01, 2006 9:45 AM
To: dev at fdo.osgeo.org
Subject: RE: [fdo-dev] Classes and properties in SHP providers




Not if things deteriorate to such a point that one has to handle as many
cases as there are providers. There would be no point to FDO in such a
case. So we have to be careful about how many capabilities we add. We
don't want to be another DirectX (although 10 years on they are finally
removing capabilities checking from the DirectX 10 API to ship with
Vista)

Traian

  

-----Original Message-----
From: Mateusz Loskot [mailto:mateusz at loskot.net] 
Sent: Wednesday, November 01, 2006 9:42 AM
To: dev at fdo.osgeo.org
Subject: Re: [fdo-dev] Classes and properties in SHP providers

Dan Stoica wrote:
>> Currently, I've not discovered any better way of development of FDO
> generic utils than checking for capabilities and react properly.
> 
> Checking the capabilities is a natural approach. It's just like 
> writing multi-platform code.

Dan,

Yes, exactly.

Cheers
--
Mateusz Loskot
http://mateusz.loskot.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe at fdo.osgeo.org For additional
commands, e-mail: dev-help at fdo.osgeo.org




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe at fdo.osgeo.org
For additional commands, e-mail: dev-help at fdo.osgeo.org