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

[Andy Morsell]

+1 Andy


-----Original Message-----
From: Tom Fukushima [mailto:tom.fukushima at autodesk.com] 
Sent: Monday, July 27, 2009 9: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