Changes between Initial Version and Version 1 of MapGuideRfc117


Ignore:
Timestamp:
Jun 20, 2011, 5:55:02 AM (13 years ago)
Author:
jng
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • MapGuideRfc117

    v1 v1  
     1
     2= !MapGuide RFC 117 - Desktop Platform API =
     3
     4This page contains a change request (RFC) for the !MapGuide Open Source project.
     5More !MapGuide RFCs can be found on the [wiki:MapGuideRfcs RFCs] page.
     6
     7
     8== Status ==
     9
     10||RFC Template Version||(1.0)||
     11||Submission Date||(Date / Time submitted)||
     12||Last Modified||20 June 2011||
     13||Author||Jackie Ng||
     14||RFC Status||draft||
     15||Implementation Status||pending||
     16||Proposed Milestone||2.3||
     17||Assigned PSC guide(s)||(when determined)||
     18||'''Voting History'''||(vote date)||
     19||+1||||
     20||+0||||
     21||-0||||
     22||-1||||
     23||no vote|| ||
     24
     25== Overview ==
     26
     27This RFC proposes a desktop-based implementation of the MapGuide Platform API.
     28
     29== Motivation ==
     30
     31Snipped from the [http://trac.osgeo.org/mapguide/wiki/Future/DesktopSdk Futures] article ...
     32
     33> MapGuide contains all of the features of a great desktop mapping component: Data access, rudimentary GIS, stylization and more.
     34>
     35> Although the current build is tightly bound to a server service, it would be useful to create a build profile (free of any server dependencies) that provided a desktop developer to quickly add spatial visualisation and interactivity to their application.
     36
     37The web and server-centric nature of MapGuide means that it is currently not possible to have a '''truly''' disconnected desktop client mapping application. Under MapGuide 6.5, this was somewhat possible by using the technique of embedding the ActiveX viewer control and loading a MWF filled with static layer data. Under the current MapGuide, there is nothing that approaches this kind of setup in terms of installation and resource footprint. Currently, if you want to build a MapGuide "desktop" application, you '''have''' to have a MapGuide Server and Web Tier present on the desktop and incur the overhead of having both of these running at the same time.
     38
     39Clayton Hotson's [http://au.autodesk.com/?nd=class&session_id=5241 AU 2009 Presentation] showed that it was indeed possible to utilize components of the MapGuide stack '''outside''' of the MapGuide Server to create applications that have no server or web tier dependencies (in the case of the AU presentation: A map renderer).
     40
     41The MapGuide Platform API itself is already modular and abstract enough to have an implementation in MapGuide/AIMS and another implementation in AutoCAD Map3D. What would be really nice is to take the concepts from that presentation to its logical conclusion, into a separate '''desktop-based''' implementation of the MapGuide Platform API
     42
     43== Proposed Solution ==
     44
     45A desktop-implementation of the MapGuide API currently exists on [http://mg-desktop.googlecode.com Google Code]. This desktop API implements the abstract classes and interfaces defined in the Platform API:
     46
     47 * MgMapBase
     48 * MgLayerBase
     49 * MgSelectionBase
     50 * MgFeatureService
     51 * MgResourceService
     52 * MgFeatureReader
     53 * MgDataReader
     54 * MgSqlDataReader
     55 * ... others
     56
     57In addition, several MapGuide Server-specific APIs have also been ported across:
     58
     59 * MgDrawingService
     60 * MgRenderingService
     61 * MgTileService
     62
     63In terms of implementation details:
     64
     65MgFeatureService for the desktop is a thin wrapper around FDO. Each service API maps to its corresponding FDO command.
     66
     67MgResourceService for the desktop wraps a pre-defined directory on the native filesystem. Package loading is also implemented allowing for spatial data portability between a MapGuide Server and an application using the Desktop Platform API.
     68
     69MgMapBase, MgLayerBase and MgSelectionBase are near 1:1 copies of their MapGuide Server counterparts. Because the desktop implementation does not have to address http statelessness like the MapGuide Web API, the Open() and Save() and Create() methods of MgMapBase are not required and have been removed from the desktop implementation.
     70
     71MgFeatureReader, MgDataReader and MgSqlDataReader wraps their respective FDO reader interfaces.
     72
     73This desktop implementation fulfils the data access (MgFeatureService) and rendering/stylization (MgRenderingService) requirements needed to build a functional desktop mapping application.
     74
     75This desktop implementation also includes a functional .net wrapper API, created via the existing SWIG infrastructure already present in the MapGuide source tree.
     76
     77As already mentioned, the desktop implementation does not have to address http statelessness like the MapGuide Web API, as such certain concepts no longer apply when moving to the desktop:
     78
     79 * Sessions
     80 * Map names
     81 * Authentication
     82 * Resource Security
     83
     84As a result, the code you would write has been greatly simplified. Here's some examples (in .net)
     85
     86Creating a runtime map:
     87
     88{{{
     89using OSGeo.MapGuide;
     90
     91...
     92
     93public void CreateMap()
     94{
     95   MgResourceIdentifier mapId = new MgResourceIdentifier("Library://Samples/Sheboygan/Maps/Sheboygan.MapDefinition");
     96
     97   MgdMap map = new MgdMap(mapId);
     98
     99   //That's it! You can now pass it to MgRenderingService to render images
     100   //No need to Open() or Save() like you would normally do with the
     101   //MapGuide Web API
     102}
     103}}}
     104
     105Accessing Services:
     106
     107{{{
     108using OSGeo.MapGuide;
     109...
     110
     111public void CreateServices()
     112{
     113   //Use the MgServiceFactory class to create your required services
     114
     115   MgdFeatureService featSvc = MgServiceFactory.CreateFeatureService();
     116   MgdResourceService resSvc = MgServiceFactory.CreateResourceService();
     117   MgRenderingService renSvc = MgServiceFactory.CreateRenderingService();
     118}
     119}}}
     120
     121Staying close to the naming conventions established in MapGuide, the desktop implementations of abstract classes in PlatformBase are prefixed "Mgd". Thus MgdMap is the desktop implementation of MgMapBase, MgdFeatureService is the desktop implementation of MgFeatureService, etc, etc. All these implementations can be upcasted, allowing them to be used with any existing code that targets these parent classes, allowing for the same level of code reuse that currently exists between AutoCAD Map3D and MapGuide.
     122
     123This RFC proposes that the desktop implementation that currently resides in Google Code be integrated into the offical MapGuide Source Tree. Doing so allows us to have a desktop API that will automatically gain all the enhancements/bugfixes that are made to the shared components. In addition, we can reuse the existing SWIG recipe files because both desktop and server will be using the same header files, allowing for reusable .net wrapper assemblies. The SWIG recipe files hosted on Google Code currently generate a monolithic .net assembly.
     124
     125== Implications ==
     126
     127Like AutoCAD Map3D, certain aspects of the Platform API does not translate cleanly from the MapGuide Server context. As such the following functionality is currently not implemented (and throws MgNotImplementedException when invoked).
     128
     129 * MgResourceService
     130   * EnumerateRepositories
     131   * CreateRepository
     132   * DeleteRepository
     133   * UpdateRepository
     134   * GetResourceHeader
     135   * ChangeResourceOWner
     136   * InheritPermissionsFrom
     137   * GetRepositoryContent
     138   * GetRepositoryHeader
     139   * EnumerateReferences
     140   * EnumerateUnmanagedData
     141
     142 * MgFeatureService
     143   * ExecuteSqlQuery (version that supports parameters/transactions)
     144   * ExecuteSqlNonQuery (version that supports parameters/transactions)
     145   * DescribeWfsFeatureType
     146   * GetWfsFeature
     147   * GetSchemaMapping
     148
     149In terms of compatibility, existing MapGuide application code is compatible at the source code level provided the code is targeting the subset of the MapGuide API that is supported and implemented by this desktop API.
     150
     151Once integrated into the MapGuide Source tree, it is possible for binary compatibility provided the client application is targeting the same shared wrapper components (Foundation, Geometry, PlatformBase, MdfModel, MdfParser) and that the desktop and server were built from the same source code revision as the desktop API can utilise the existing SWIG recipe files. Or to put it in simpler words: A .net application that references:
     152
     153 * OSGeo.MapGuide.Foundation.dll
     154 * OSGeo.MapGuide.Geometry.dll
     155 * OSGeo.MapGuide.PlatformBase.dll
     156
     157Should be able to work on the desktop API, which would have identically generated assemblies.
     158
     159It is planned, should this RFC be approved, to put the migrated source into a "Desktop" top-level directory under MgDev. This will have minimal impact on the rest of the source tree.
     160
     161Also if it hasn't been made clear already, this RFC only concerns the desktop API and not something like a desktop map viewer. The intention behind this RFC is to add the infrastructure to make it possible for such applications to be created. A desktop map viewer may exist in the future as a separate RFC.
     162
     163There are no plans to make this desktop API production ready for the 2.3 milestone. The scope of this RFC is to simply have the source of the desktop implementation integrated into the MapGuide source tree by that stage.
     164
     165== Test Plan ==
     166
     167The desktop implementation already uses a near-identical test suite as the MapGuide Server and thus already has the same level of code coverage.
     168
     169== Funding / Resources ==
     170
     171Community