[mapguide-dev] Unmanaged Data APIs RFC

Fri Dec 8 15:18:18 EST 2006

If the GetUnmanagedDataMapping API does not get used by the Studio, then we should drop it as well since the Site Admin has other external APIs to retrieve/save these information.

Steve.

  _____  

From: Tony Fang 
Sent: Friday, December 08, 2006 12:12 PM
To: dev at mapguide.osgeo.org
Subject: RE: [mapguide-dev] Unmanaged Data APIs RFC

After a little thought and discussion with Bruce Dechant, I’m removing the SetUnmanagedDataMapping method as it would be security problem - essentially providing  any user unfettered access to the server machine. You will be able to modify the unmanaged data mappings via the Server Admin API.

Thanks,

Tony Fang

  _____  

From: Tony Fang 
Sent: Thursday, December 07, 2006 4:47 PM
To: dev at mapguide.osgeo.org
Subject: RE: [mapguide-dev] Unmanaged Data APIs RFC

Thanks Steve.

After some discussion with Steve, we came up with the following changes to the API. Note the changes to the depth parameter and the addition of the GetUnmanagedDataMapping method.

Thanks,

Tony Fang

virtual MgStringCollection * MgResourceService::EnumerateUnmanagedData(CREFSTRING mappingName, CREFSTRING dataTypeFilter, INT32 depth); 

Enumerates the available unmanaged data from the server. 

Parameters: 

mappingName specifies which mappingName to use to return the unmanaged data. When set to empty string it will use all mappings.

dataTypeFilter is a filter on the returned data. E.g. SHP, SDF, DWF, RASTER, FOLDER. Empty string will return all data types. FOLDER returns a list of subfolders. 

depth is how many levels of subfolders it should search for data. -1 to search all depths, 0 to search only the top level, 1 to search 1 level, 2 to search 2 levels, etc. 

Returns: 

Returns an MgStringCollection containing the available unmanaged data files. 

virtual MgStringCollection * MgResourceService::EnumerateUnmanagedDataMappings(); 

Enumerates the unmanaged data mappings. 

Parameters: 

None. 

Returns: 

Returns an MgStringCollection containing only the mapping names. 

virtual void MgResourceService::SetUnmanagedDataMapping(CREFSTRING mappingName, CREFSTRING mappingValue); 

Sets the unmanaged data mapping. If the mapping does not exist, it adds it. If it does exist, it will set it to the new path. 

Parameters: 

mappingName is the mapping name. 

mappingValue is the mapping path. 

Returns: 

Returns nothing. 

(new addition)

virtual STRING MgResourceService::GetUnmanagedDataMapping(CREFSTRING mappingName); 

Returns the unmanaged data mapping value. 

Parameters: 

mappingName is the mapping name. 

Returns: 

Returns the unmanaged data mapping value.

  _____  

From: Steve Dang 
Sent: Thursday, December 07, 2006 3:20 PM
To: dev at mapguide.osgeo.org
Subject: RE: [mapguide-dev] Unmanaged Data APIs RFC

For cross platform compatibilities (i.e. Linux only supports ‘/’s while Windows supports both ‘/’s and ‘¥’s), pathnames referenced in the XML document and the serverconfig.ini file should always contain forward slashes (‘/’s) instead of backward slashes (‘¥’s).

Thanks,

Steve.

  _____  

From: Tony Fang 
Sent: Wednesday, December 06, 2006 4:10 PM
To: dev at mapguide.osgeo.org
Subject: RE: [mapguide-dev] Unmanaged Data APIs RFC

I’ve updated the Unmanaged Data APIs RFC.

http://wiki.osgeo.org/index.php/MapGuide_RFC_2_-_Unmanaged_Data_APIs

The main change is the addition of the 3 Resource Service API functions. 

Please have a look and post any feedback to the group.

Thanks,

Tony Fang

The folllowing API functions will be added to the Resource Service: 

virtual MgStringCollection * MgResourceService::EnumerateUnmanagedData(CREFSTRING dataTypeFilter, INT32 depth); 

Enumerates the available unmanaged data from the server. 

Parameters: 

dataTypeFilter is a filter on the returned data. E.g. SHP, SDF, DWF, RASTER, FOLDER. Empty string will return all data types. FOLDER returns a list of subfolders. 

depth is how many levels of subfolders it should search for data. 0 to search all subfolders, 1 to search only the top-level, 2 to search down one subfolder, etc. 

Returns: 

Returns an MgStringCollection containing the available unmanaged data files. 

virtual MgStringCollection * MgResourceService::EnumerateUnmanagedDataMappings(); 

Enumerates the unmanaged data mappings. 

Parameters: 

None. 

Returns: 

Returns an MgStringCollection containing the mappings. 

virtual void MgResourceService::SetUnmanagedDataMapping(CREFSTRING mapping, CREFSTRING path); 

Sets the unmanaged data mapping. If the mapping does not exist, it adds it. If it does exist, it will set it to the new path. 

Parameters: 

mapping is the mapping name. 

path is the mapped path. 

Returns: 

Returns nothing. 

  _____  

From: Bill Dhimitri 
Sent: Friday, November 10, 2006 7:38 AM
To: dev at mapguide.osgeo.org
Subject: RE: [mapguide-dev] Unmanaged Data APIs RFC

Hi Tony,

I think this looks good so far.  One thing that might be worth clarifying is the API to enumerate the unmanaged data files

1)       Should the API provide a way to filter what is returned by file type?  For example, maybe the caller wants just a list of SHP files.  Or just a list of ECW files. Etc. I am assuming that the API would allow filtering based on a specific mapping (your example shows a list from “all” mappings).

2)       Should the API provide control over the depth of the search into the directory sub-structure?  For example, the caller might want only those files in the top-most folders.  The concern here is that if I have a very large directory substructure with thousands of files, there could be a performance hit…

3)       Should the API provide a way to get a list of sub-folders?  Here, I am thinking about FDO which allows a folder (as opposed to a file) to be treated as a data source. FDO does this for raster and SHP/DBF/PRJ files.  Notice that today, MapGuide Studio does not directly support the notion of a data source that consists of a folder containing SHP/DBF/PRJ files, but FDO and the MapGuide server handle this scenario just fine.  Another common scenario that would be helped by this is a folder that contains say 500 geo-contiguous raster files.  It’s much more convenient to treat the folder as a single data source, rather than deal with each individual file.

Bill

  _____  

From: Tony Fang 
Sent: Friday, November 03, 2006 7:41 PM
To: dev at mapguide.osgeo.org
Subject: RE: [mapguide-dev] Unmanaged Data APIs RFC

I’ve updated the RFC with the drive mappings suggestion. Any feedback on the returned list of drive mappings (using square brackets on the drive mapping name) would be appreciated.

The server's unmanaged data directories will be specified using the serverconfig.ini. A new section defining directory mappings will be used to specify the unmanaged data directories. 

For windows, it may look like this: 

[Unmanaged Data Mappings]
SomeSdfFiles = c:¥mydata¥sdf
Some Shp Files = d:¥otherdata¥shp
BigArseImages = ¥¥some_other_machine¥data¥images
Some 很大中文 DwfFiles = c:¥mydata¥很大中文Dwf
大きsdf = c:¥mydata¥bigsdf 

For linux, it may look like this: 

[Unmanaged Data Mappings]
SomeSdfFiles = /usr/mydata/sdf
Some Shp Files = /usr/otherdata/shp
BigArseImages = /mnt/some_other_machine/data/images
Some 很大中文 DwfFiles = /usr/mydata/很大中文Dwf
大きsdf = /usr/mydata/bigsdf 

Unicode characters are supported in the mapping names. Spaces in the mappings are also supported. Square brackets [ and ] are not allowed. They are reserved characters for the serverconfig.ini section titles. 

We will add API methods to return the unmanaged data mappings, set the mappings, and also verify that the mappings are valid and accessible. 

We will add an API to enumerate the unmanaged data files available on the server machine. The files will be prefaced with their mapping names. You may enumerate all files from all the available drive mappings, or you may select a single drive mapping. 

A returned list from all available drive mappings may look like this: 

[SomeSdfFiles]world.sdf
[Some Shp Files]ecuador.shp
[Some 很大中文 DwfFiles]large.dwf
[Some 很大中文 DwfFiles]subdir/Big.dwf
[大きsdf]reallybig.sdf 

Thanks,

Tony

  _____  

From: Robert Bray [mailto:rbray at robertbray.net] 
Sent: Friday, November 03, 2006 9:05 AM
To: dev at mapguide.osgeo.org
Subject: Re: [mapguide-dev] Unmanaged Data APIs RFC

Jason,

Good questions. In addition I think it would make sense / be highly desirable for all RFCs that add or modify APIs to include more detail with respect to those changes. It would be nice to see the actual API function signatures for example.

Bob

Jason Birch wrote: 

That would be cool.  That way we can have a theme, and a nested hierarchy within that theme if we need the complexity.  Are we restricted to single-word mappings, or will spaces be supported?  ASCII characters only or full internationalisation?

What about schema changes?  Will there be a way of updating the repository's knowledge of unmanaged data schemae?  Or are these maybe cached on a session basis like the RDBMS schemae?

There would also need to be a method that allows the author UIs to validate resources that reference unmanaged data sources, to make sure that any dependancies (properties, maptips, themes, etc) are still valid, and give a graphical indication when the world slips.

Jason

________________________________

From: Robert Bray [mailto:rbray at robertbray.net]
Sent: Thu 2006-11-02 10:46 PM
To: dev at mapguide.osgeo.org
Subject: Re: [mapguide-dev] Unmanaged Data APIs RFC

I too am concerned this will make data management hard for people with lots of data / multiple projects. It might be better to dedicate a section in serverconfig.ini to define path mappings as follows:

[Path Mappings]
SomeSdfFiles = <some path>
SomeShpFiles = <some other path>
BigArseImages = <path to SAN disk>
...

In Studio / Web Studio the user would be presented the list of path mappings. Once they select a path mapping they can browse all files and folders below that path.

My 2 cents...

Bob

--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe at mapguide.osgeo.org For additional commands, e-mail: dev-help at mapguide.osgeo.org 

  _____  

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe at mapguide.osgeo.org
For additional commands, e-mail: dev-help at mapguide.osgeo.org

--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe at mapguide.osgeo.org For additional commands, e-mail: dev-help at mapguide.osgeo.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide-internals/attachments/20061208/28e25bc0/attachment.html