Saturday, 3 January 2015

Brainstorming: A pure .net MapGuide API

Here is something that just entered into my stream of consciousness.

Is it worth building a pure .net MapGuide API? Note that my question is not "can we?" but rather "should we?"

Because what is the MapGuide API technically speaking? It is nothing more than a C++ object-oriented abstraction of a TCP/IP connection to a MapGuide Server process. We can easily build the same abstractions in .net (using TcpClient). The real "effort" is figuring out the wire formats and protocols for how data is to be sent and received via TCP/IP to the MapGuide Server process, and you know what? Maestro has already figured out some of that, and for the rest we can always refer to the MapGuide source code and see how they do it.

This pure .net approach would give us an API surface area similar to what is currently offered by the official MapGuide API, except for:

  • Coordinate System APIs (we can't exactly port that over to .net)
  • Geometry APIs (likewise)
Which isn't exactly bad news as these parts are replaceable/interchangeable. That's what we already do in the Maestro API, we let NetTopologySuite handle geometry duties and farm coordinate system functionality off to Proj.Net

If P/Invoke (the mechanism by which the SWIG-generated libraries work in .net) proves to be too much of a pain to deal with for vNext, this pure .net approach could be a feasible alternative provided you are willing to give up the use of MgCoordinateSystem, MgGeometry and friends. In return, you would have a single, 100% managed, NuGet-able library that has none of the bitness, dll and deployment problems that is symptomatic of the current .net MapGuide API, but with 80% of the functionality.

So what do you think? Would this be something you would use for building your own MapGuide applications in .net? If you already use the Maestro API for building your applications, I guess that answer would be yes.

These thoughts are brought to you by Microsoft's announcement of open sourcing .net and their next version of, and my firing synapses thinking about how .net MapGuide applications can be a first-class citizen in both Windows and Linux in this new exciting .net world.


kuba said...


One thing that limit us in developing new apps for MapGuide is PHP. Beeing able build solutions without PHP on top of MapGuide inluding Fusion, MapGuide API, mg-rest would be great. For example, we're still using Ajax rather than Fusion just because we're safe in what we're doing.

Thanks a lot.

Wilson H said...

imagine node js mapguide.. imagine the possibility to port it to mobile devices trough an API...

man, i gladly accept an .net implementation to be able to overcome the problems you mentioned in this article.