Changes between Version 6 and Version 7 of Future/DesktopSdk


Ignore:
Timestamp:
Jan 3, 2010, 1:52:24 PM (14 years ago)
Author:
jbirch
Comment:

Suppress unintended links

Legend:

Unmodified
Added
Removed
Modified

  • Future/DesktopSdk

    v6 v7  
    33This page is part of the [wiki:Future MapGuide Future] section, where ideas are proposed and refined before being turned into RFCs (or discarded).  Visit the [wiki:Future] page to view more!
    44
    5 ''Most of this is based on observation and light analysis of the MapGuide source code. Some of this stuff may sound nonsensical because I have totally misunderstood the purpose of a given component/library. MapGuide Developers, feel free to correct any mistakes''
     5''Most of this is based on observation and light analysis of the !MapGuide source code. Some of this stuff may sound nonsensical because I have totally misunderstood the purpose of a given component/library. !MapGuide Developers, feel free to correct any mistakes''
    66
    77= Overview =
    88
    9 MapGuide contains all of the features of a great desktop mapping component:  Data access, rudimentary GIS, stylization and more. 
     9!MapGuide contains all of the features of a great desktop mapping component:  Data access, rudimentary GIS, stylization and more. 
    1010
    1111Although 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.
    … …  
    1313= SDK contents =
    1414
    15 A MapGuide desktop SDK would most likely have these projects (in source form or dll/headers/libs) as the "core"
     15A !MapGuide desktop SDK would most likely have these projects (in source form or dll/headers/libs) as the "core"
    1616
    1717 * Common/CoordinateSystem
    … …  
    3232If we were to take the Geospatial Platform API in AutoCAD Map as an example, the desktop-specific components would be:
    3333
    34  * A desktop-based implementation of PlatformBase, that would mainly be providing desktop implementations of:
    35    * MgFeatureService
    36    * MgResourceService
    37    * MgMapBase
    38    * MgSelectionBase
     34 * A desktop-based implementation of !PlatformBase, that would mainly be providing desktop implementations of:
     35   * !MgFeatureService
     36   * !MgResourceService
     37   * !MgMapBase
     38   * !MgSelectionBase
    3939   * other abstract classes(?)
    4040
    41 The MgResourceService implementation would have to use an alternative to Berkeley DBXML due to licensing issues. Possible alternatives for a MgResourceService backing store include:
     41The !MgResourceService implementation would have to use an alternative to Berkeley DBXML due to licensing issues. Possible alternatives for a !MgResourceService backing store include:
    4242
    4343 * [http://modis.ispras.ru/sedna/ Sedna XML DB]
    4444 * SQLite ?
    45  * Native filesystem with some sort of MgResourceIdentifier <-> file path addressing scheme.
     45 * Native filesystem with some sort of !MgResourceIdentifier <-> file path addressing scheme.
    4646
    47 In terms of handling the managed/unmanaged resources divide, a desktop-based MapGuide could use a Sedna/directory combination or just simply a series of directories (one for each alias + one special directory for managed resources)
     47In terms of handling the managed/unmanaged resources divide, a desktop-based !MapGuide could use a Sedna/directory combination or just simply a series of directories (one for each alias + one special directory for managed resources)
    4848
    49 Implementing MgFeatureService should be easy, since most methods in MgFeatureService are 1:1 with the FDO API
     49Implementing !MgFeatureService should be easy, since most methods in !MgFeatureService are 1:1 with the FDO API
    5050
    51 This may sound like a case of NIH, seeing as MapGuideCommmon already provides an implementation of PlatformBase. The problem is that MapGuideCommon's implementation of PlatformBase has all the server/ACE/dbxml dependencies that we don't want or need in a desktop context (obviously because the server is using this library). The reason MapGuideCommon would exist in the desktop SDK is so that a desktop-based MapGuide can interop with a MapGuide Server, as we are currently doing in the Web Tier.
     51This may sound like a case of NIH, seeing as !MapGuideCommmon already provides an implementation of !PlatformBase. The problem is that !MapGuideCommon's implementation of !PlatformBase has all the server/ACE/dbxml dependencies that we don't want or need in a desktop context (obviously because the server is using this library). The reason !MapGuideCommon would exist in the desktop SDK is so that a desktop-based !MapGuide can interop with a !MapGuide Server, as we are currently doing in the Web Tier.
    5252
    5353= MapGuide Server Integration =
    5454
    55 A desktop-based MapGuide should have some form of integration/compatibility with MapGuide Server.
     55A desktop-based !MapGuide should have some form of integration/compatibility with !MapGuide Server.
    5656
    5757== API ==
    … …  
    5959On the API side of things, this implementation would have the same API parity as the AutoCAD Map Geospatial Platform API and have the same limitations:
    6060
    61  * No MgRenderingService
    62  * No MgMappingService
    63  * No MgDrawingService
    64  * No MgKmlService
    65  * No MapGuide Server specific APIs (eg. MgSite, MgSiteConnection)
     61 * No !MgRenderingService
     62 * No !MgMappingService
     63 * No !MgDrawingService
     64 * No !MgKmlService
     65 * No !MapGuide Server specific APIs (eg. !MgSite, !MgSiteConnection)
    6666
    6767== Resource Compatibility ==
    6868
    69 A desktop-based implementation should be able to support all of the required MapGuide resource types, with the exception of:
     69A desktop-based implementation should be able to support all of the required !MapGuide resource types, with the exception of:
    7070
    71  * WebLayout
    72  * ApplicationDefinition
    73  * PrintLayout (since we're not implementing MgMappingService)
    74  * DrawingSource (if we want no DWF dependency)
    75  * SymbolLibrary (if we want no DWF dependency)
     71 * !WebLayout
     72 * !ApplicationDefinition
     73 * !PrintLayout (since we're not implementing !MgMappingService)
     74 * !DrawingSource (if we want no DWF dependency)
     75 * !SymbolLibrary (if we want no DWF dependency)
    7676
    7777Namely, because these are web-specific resources that have cannot really be translated into a desktop context. Every other resource type should be consumable in a desktop context.
    … …  
    7979== Data ==
    8080
    81 Since a desktop implementation would have to implement MgResourceService::ApplyPackage(), MGP packages would be easily reusable in a desktop context, only web-specific resources would be ignored/discarded when loaded into a desktop context.
     81Since a desktop implementation would have to implement MgResourceService::!ApplyPackage(), MGP packages would be easily reusable in a desktop context, only web-specific resources would be ignored/discarded when loaded into a desktop context.
    8282
    83 Ideally there should be some way to consume MapGuide server layers directly, and the easiest solution for that would be to implement a [http://themapguyde.blogspot.com/2009/11/why-not.html MapGuide FDO Provider]. That way MapGuide can function like a WFS/WMS server, but you get all the nice FDO metadata that may have been lost by going through WFS/WMS. A MapGuide FDO provider would allow for '''dead simple''' replication of MapGuide Feature Sources.
     83Ideally there should be some way to consume !MapGuide server layers directly, and the easiest solution for that would be to implement a [http://themapguyde.blogspot.com/2009/11/why-not.html MapGuide FDO Provider]. That way !MapGuide can function like a WFS/WMS server, but you get all the nice FDO metadata that may have been lost by going through WFS/WMS. A !MapGuide FDO provider would allow for '''dead simple''' replication of !MapGuide Feature Sources.
    8484
    8585= A desktop application framework =
    8686
    87 At this point we would have a MapGuide API that is totally functional in a desktop context, free of any server dependencies and/or idioms. The only thing missing is the application side of things. If we want users to be able to build desktop MapGuide applications with very little programming knowledge, then we would need a desktop-based equivalent to the WebLayout/ApplicationDefinition.
     87At this point we would have a !MapGuide API that is totally functional in a desktop context, free of any server dependencies and/or idioms. The only thing missing is the application side of things. If we want users to be able to build desktop !MapGuide applications with very little programming knowledge, then we would need a desktop-based equivalent to the !WebLayout/ApplicationDefinition.
    8888
    8989This framework would have a library of pre-defined widgets, so that the out-of-the-box functionality matches your basic AJAX/Fusion viewer: