[mapguide-internals] Motion: vote RFC 77 - Create Feature Source

[Tom Fukushima]

Hi,

I motion for a vote on

Motion: vote RFC 77 - Create Feature Source
http://trac.osgeo.org/mapguide/wiki/MapGuideRfc77

+1 Tom

Here is the summary of the review:


1. It will support SHP and SQLite only because ORG & DGAL FDO provider is a read-only provider. It doesn't support FdoICreateStore command. So we can't do it.

2. For method GetFileOrFolderName(), folder name is used for SHP only currently. For example, if you want to create multiple shp files, a folder name need to be specified instead of a file name. Actually file or folder name here are the relative path file or folder name. All created files are located in Respositories\Library\DataFiles\xxxxxxxxxxxxxx\.


1.       In implications section, point out specifically that method MgFeatureService::CreateFeatureSourceSQLite will support SHP, SDF and SQLite only because other file-based FDO providers don't support FdoICreateDataStore command.

2.       Modify name of the following two methods.

a)         GetFileOrFolderName -> GetFileName.

b)         GetFileOrFolderName -> GetFileName.



1. Should the class name be changed? "MgCreateSdfParams" is a bit misleading.

Yes. It is a little misleading. However, we can't change it because it may break backward compatibility of current MapGuide Web API.



2. If the provider supports all required calls, will this work with any provider? Eg. if the OGR provider is fixed, or a new provider is made, will the call work, or is there a "supported providers" check?

We have to have a supported providers check now. So if some new file-based providers supports FdoICreateStore in the future, we have to do some additional works. The parameters of different providers for command FdoICreateStore is different. MgFileFeatureSourceParams doesn't have a FdoIDataStorePropertyDictionary as FdoICreateStore command. So we can't do it. Moreover, SHP file is created by FdoIApplySchema instead of FdoICreateStore.



3. just wondering if the limitation to file based feature sources is imperative. Maybe its worthwhile to keep the API sufficiently generic to permit easy extensions at a later time.

We support file-based feature sources only because of limited resource. Currently API is still generic. MgFeatureSourceParams is a pure virtual class without any members. So we can create a very generic class if we want to support other types of data store in the future.



4. Given the correct connector is available on the used server deployment what's missing to extend that to the generic case?

There is no very specific reason that we can't extend it to the generic case. The only reason is we don't have enough resource to support all of providers because it need not only development efforts but also testing efforts.

Thanks
Tom