[mapguide-internals] Discussion: Taking MapGuide beyond the
server/web tier and into the desktop
martin.morrison at edsi.com
Mon Jan 4 08:29:18 EST 2010
I would presume this would be as a new product (MapGuide Portable?), while keeping the existing MapGuide for internet server use?
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jackie Ng
Sent: Monday, January 04, 2010 8:12 AM
To: mapguide-internals at lists.osgeo.org
Subject: [mapguide-internals] Discussion: Taking MapGuide beyond the server/web tier and into the desktop
Re-posted from Google Wave, because it seems my waves of interest haven't
been updated in ages :/
Just want to start some discussion about another interesting topic: A
desktop-based MapGuide API.
I was bored over the xmas/NY break, so I've been studying the MapGuide
source and seeing how the MapGuide Platform API could be applied in a purely
The MapGuide API offers plenty of functionality in one package. However of
the two known implementations:
- One has heavy MapGuide Server/Web tier dependencies
- One is tightly bound to AutoCAD Map
What would be really nice, is an implementation of the MapGuide API with *
little* to *no* such dependencies. The beauty of the FDO API is that in
terms of binary footprint, it's simply just a bunch of dlls and one
providers.xml files. The client FDO application simply needs to have these
libraries in the same directory and they're off and racing. MapGuide
unfortunately currently does not have such a rosy deployment story.
At a high level, implementation of a desktop-based MapGuide API, would seem
pretty straight forward. You would be basically implementing your own
- Other Mg* abstract classes
And the result would be a MapGuide API that is free of any server/web
dependencies, and as a result, would also be quite light-weight as well.
At a lower level, we start to see some roadblocks. Without beating round the
bush, the main roadblock here is MgResourceService
Implementation-wise, everything else looks relatively easy:
- MgFeatureService: It's just a wrapper around FDO with utility classes
to convert to/from MG and FDO data types.
- MgMapBase, MgLayerBase, MgSelectionBase: You could effectively reuse
the existing MG implementation here.
- In fact, you could base most of the abstract PlatformBase classes from
the existing MapGuide implementations.
MgResourceService uses Berkeley DBXML for the MapGuide implementation, and
(I presume) DWG for the AutoCAD Map implementation.
Unfortunately it seems that DBXML is not usable for a desktop MG
implementation due to the un-friendly licensing surrounding the component.
Thus an alternative is needed for a desktop-based MapGuide implementation.
I've looked at Jason's suggestion of Sedna <http://modis.ispras.ru/sedna> as
an alternative and it looks like a viable alternative, but there are some
issues I've found:
- There are no APIs for data store management. I would have to use
command-line tools in the Sedna distribution to create/maintain these
- It is not embeddable :-( The total projected library/executable
footprint would probably be just slightly smaller than MapGuide Server
So while Sedna may give a functional desktop MgResourceService implementation,
it's not going to be pretty ugly in the portability/distributable
So my question to you all is: Given the constraints
(licensing/technological), what would be the best approach to implementing a
Do we stay with XML database technology (and live with whatever ugliness it
may bring)? Or do we go with something different like a SQLite/Filesystem
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
More information about the mapguide-internals