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

[Jason Birch]

+1 Jason

I would suggest that the inline (and generated) docs for MgCreateSdfParams have specific mention that it also supports others. Future work should be done to deprecate this and use a more generic name.


----- Original Message -----
From: [hidden email] <[hidden email]>
To: MapGuide Internals Mail List <[hidden email]>
Sent: Mon Jul 27 21:27:45 2009
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Kenneth Skovhede, GEOGRAF A/S]

+1 Kenneth

Regards, Kenneth Skovhede, GEOGRAF A/S



Jason Birch skrev:

> +1 Jason
>
> I would suggest that the inline (and generated) docs for MgCreateSdfParams have specific mention that it also supports others. Future work should be done to deprecate this and use a more generic name.
>
>
> ----- Original Message -----
> From: [hidden email] <[hidden email]>
> To: MapGuide Internals Mail List <[hidden email]>
> Sent: Mon Jul 27 21:27:45 2009
> 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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>  
> ------------------------------------------------------------------------
>
> _______________________________________________
> mapguide-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>  

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[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: [hidden email] [mailto:[hidden email]] 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals


_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Paul Spencer-2]

+1 Paul

On 28-Jul-09, at 3:39 AM, Kenneth Skovhede, GEOGRAF A/S wrote:

> +1 Kenneth
>
> Regards, Kenneth Skovhede, GEOGRAF A/S
>
>
>
> Jason Birch skrev:
>> +1 Jason
>>
>> I would suggest that the inline (and generated) docs for  
>> MgCreateSdfParams have specific mention that it also supports  
>> others. Future work should be done to deprecate this and use a more  
>> generic name.
>>
>> ----- Original Message -----
>> From: [hidden email] <[hidden email]
>> >
>> To: MapGuide Internals Mail List <[hidden email]>
>> Sent: Mon Jul 27 21:27:45 2009
>> 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
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>  
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> mapguide-internals mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>
> _______________________________________________
> mapguide-internals mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals

__________________________________________

    Paul Spencer
    Chief Technology Officer
    DM Solutions Group Inc
    http://research.dmsolutions.ca/

_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Andy Morsell]

+1 Andy


-----Original Message-----
From: Tom Fukushima [mailto:[hidden email]]
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



_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Leaf Li]

Hi Trevor,

Thanks for your clarification.

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.
[Leaf] Yes. MgCreateSdfParams isn't used to implement creators for SHP and SQLite. Actually MgFileFeatureSourceParams is enough for SDF, SHP and SQLite. We keep MgCreateSdfParams in case some existing application still uses it and this change doesn't break their application. I will mark mark MgCreateSdfParams as deprecated in comments for this class. In the future, we can remove it completely.

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.
[Leaf] This is a typo. It should be MgFeatureService::CreateFeatureSource(...).

Thanks,
Leaf Li
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

[Tom Fukushima]

This RFC has been adopted.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Tom Fukushima
Sent: Monday, 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-internals