MapGuide RFC 2 - Unmanaged Data APIs

This page contains an change request (RFC) for MapGuide Open Source. More MapGuide RFCs can be found on the MapGuide RFCs page.

=Status=

=Overview=

Managed data is data contained inside the server's data repository. Unmanaged data is any data outside of the server's data repository.

We want to add server/web functionality and APIs which will allow Studio to create feature sources from unmanaged data. To accomplish this, directories accessible by the server machine can be specified as unmanaged data directories. APIs will be added which will enumerate the available unmanaged data files from the specified unmanaged data directories.

WebStudio can also make use of these APIs to create unmanaged feature sources.

=Motivation=

When Studio is used to create a feature source (e.g. using Load Procedure), the data files (e.g. sdf, shp, raster, dwf, odbc) are uploaded to the server's repository (managed data). This is not an issue when the data files are small. If Studio and Server are on the same machine, this uploading is an unnecessary duplication of the data file. If the data file is really large, the copying is slow and it consumes unnecessary hard-drive space.

Currently, a feature source which references unmanaged data can be created. But it must be done manually. The exact path to the data file on the server machine must be known. Then the Feature Source XML must be manually edited and uploaded to the server via the web tier. This is a cumbersome process.

We want to automate this workaround in Studio. To do this, additional APIs and functionality will be added to the server/web. Directories accessible by the server machine can be specified as unmanaged data directories. APIs will be added which will enumerate the available unmanaged data files. Thus direct access to the server machine's file system will no longer be required. Creation of unmanaged data feature sources can now be created remotely.

The API will only enumerate data files contained in the directories and subdirectories specified by the server. For security reasons we do not want to allow the API to return data files in directories which are not specified. For windows, specified directories can be physical drives or network paths. For linux, it can be any accessible path.

=Proposed Solution=

The proposed changes are open for discussion.

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. This section can be edited using the Server Admin API.

For windows, it may look like this:

For linux, it may look like this:

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:

The server will not be locked down such that it is restricted to those files in the Unmanaged Data Mappings. In other words, this means that a feature source can still reference a file that is not in one of the subdirectories specified by the mappings. The reason we don't have to restrict to those subdirectories is because we can use the operating system's or network's built-in security to limit access to files. It will be dependent upon the user to allow access to the files in the Unmanaged Data Mappings, otherwise they won't be very useful. Thus manually created unmanaged features sources and those created by webstudio will continue to work.

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

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

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

Enumerates the available unmanaged data from the server.

Parameters:

mappingName specifies which mapping 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. When set to empty string, it 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 STRING MgResourceService::GetUnmanagedDataMapping(CREFSTRING mappingName);

Returns the unmanaged data mapping value.

Parameters:

mappingName is the mapping name.

Returns:

Returns the unmanaged data mapping value.

=Implications=

API documentation will need to be updated.

=Test Plan=

TBD

=Funding/Resources=

Autodesk to supply the resources to make the required changes.