[mapguide-internals] Discussion: Taking MapGuide beyond the server/web tier and into the desktop

Jackie Ng jumpinjackie at gmail.com
Mon Jan 4 08:12:28 EST 2010

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
desktop-based scenario.

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
versions of:

   - MgFeatureService
   - MgResourceService
   - MgMapBase
   - MgLayerBase
   - MgSelectionBase
   - 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
   databases. Ugly.
   - 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
desktop-based MgResourceService?

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


- Jackie
Blog: http://themapguyde.blogspot.com
LinkedIn: http://www.linkedin.com/in/jackieng
Twitter: http://twitter.com/jumpinjackie

More information about the mapguide-internals mailing list