Difference between revisions of "MapGuide RFC 2 - Unmanaged Data APIs"

Revision as of 13:18, 1 November 2006

Overview

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

Add server/web functionality and APIs which will allow Studio to create feature sources from unmanaged data. We want to specify certain directories on the server machine to be unmanaged data directories. We will then add APIs which will enumerate the available unmanaged data files.

Motivation

When you use Studio 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. 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, this duplication is slow and consuming unnecessary hard-drive space.

Currently, you can create a feature source which references unmanaged data. But it must be done manually. You need to know where the data is on the server machine. Then you must edit your Feature Source XML and upload it to the server via the web tier. This is a cumbersome process.

We want to automate this workaround in Studio. To do this, we need to add additional APIs and functionality to the server/web. We want to specify certain directories on the server machine to be unmanaged data directories. We will then add APIs which will enumerate the available unmanaged data files.

Funding/Resources

Tony Fang will be the resource to implement the changes outlined in this RFC.

Proposed Changes

TBD

Technical

Server API Server Admin API

Implications

TBD

Test Plan

TBD

@@ Line 1: / Line 1: @@
 ===Overview===
-This section brefly describes the problem set, and the proposed solution in general terms.  It should be deliberately short, a couple of sentences or so.
+Managed data is data contained inside the server's data repository. Unmanaged data is any data outside of the server's data repository.
+Add server/web functionality and APIs which will allow Studio to create feature sources from unmanaged data. We want to specify certain directories on the server machine to be unmanaged data directories. We will then add APIs which will enumerate the available unmanaged data files.
 ===Motivation===
-This is the most important part of the RFC.  It describes the problem domain in detail.  Focusing on this will allow reviewers to fully understand why the proposed change is being made, and potentially suggest different/better ways of accomplishing the desired results.  The more time we spend on understanding the problem, the better our solution will be.
+When you use Studio 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. 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, this duplication is slow and consuming unnecessary hard-drive space.
+Currently, you can create a feature source which references unmanaged data. But it must be done manually. You need to know where the data is on the server machine. Then you must edit your Feature Source XML and upload it to the server via the web tier. This is a cumbersome process.
+We want to automate this workaround in Studio. To do this, we need to add additional APIs and functionality to the server/web. We want to specify certain directories on the server machine to be unmanaged data directories. We will then add APIs which will enumerate the available unmanaged data files.
 ===Funding/Resources===
-This section will confirm that the proposed feature has enough support to proceed.  This would typically mean that the entity making the changes would put forward the RFC, but a non-developer could potentially do so if they are sure they have the funding to cover the change.
+Tony Fang will be the resource to implement the changes outlined in this RFC.
 ===Proposed Changes===
-This is a more detailed description of the actual changes desired.  The contents of this section are tailored to the type of RFC - web site changes are different from technical changes for instance.  We need to develop guidelines on what the standard types of proposals are, and what sub-sections could be included here for each type.
+TBD
 ====Technical====
-This section could include details on files affected, schema changes, potential API changes etc.
+Server API
+Server Admin API
 ===Implications===
-This is wide open.
+TBD
 ===Test Plan===
-How the proposed change will be tested, if applicable
+TBD