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

[Trevor Wekel]

+1 Trevor.  Can I get some clarification on the following points?

MgFileFeatureSourceParams should be a concrete implementation if there is enough similarity in the Fdo provider implementations for SDF, SHP, and Sqlite.  This seems to be indicated by the email discussion and class hierarchy but it is not specifically called out as such in the RFC.

Based on Jason's comment regarding class naming, I agree that MgCreateSdfParams should not be used to implement creators for SHP and SQLite.  If MgFileFeatureSourceParams can implement all the functionality of MgCreateSdfParams then I think we should mark MgCreateSdfParams as deprecated.  This would leave us with a single MgFileFeatureSourceParams class with support for three providers.  This could be done under a separate RFC related to RFC 77.

What is MgFeatureService::CreateFeatureSourceSQLite?  This is not documented anywhere in the RFC.  Hopefully this is just a typo.  I think it would be good to avoid adding provider specific APIs to MgFeatureService public APIs.

Thanks,
Trevor 



-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Tom Fukushima
Sent: July 27, 2009 10:28 PM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] Motion: vote RFC 77 - Create Feature Source 

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
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals