[mapguide-internals] RE: RFC 77 - Create Feature Source is ready for review

[Leaf Li]

Hi Kenneth and UV,

I am sorry. I just found I missed your questions. The following are my answers.

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,
Leaf Li