When I was leaving my GIS job (only actually about 6 months ago because it was just before Christmas) I tried to start a dialogue with Autodesk to see if they might want to contract me part time to port the MapGuide web server extensions from native C++ to Java and .Net. They never acknowledged these attempts through the official channels though I did get to have a bit of discussion in the MapGuide open source community. I wasn't sure at that point how busy the research would keep me and whether I might be able to do that one the side. Nothing came of it.
The MapGuide platform consists of the MapGuide Server and the MapGuide web server extensions. The webs server extensions are the interface provided to web technologies to communicate with and interact with the MapGuide server. Both of these are written in native C++ but the web server extensions use SWIG to generate wrappers to Java, .Net and PHP. These wrappers are a pain for several reasons: 1) It is hard to see the library dependencies and things can go wrong if some native library dependency is not satisfied. 2) Debugging is harder because all the MapGuide objects are black boxes from the perspective or the Java or .Net platforms because the implementation is native meaning the internal state of these objects cannot be viewed by the debugger. 3) Using wrappers incurs some overhead and if SWIG is not used carefully it leaks memory. The Web Server extensions have been pretty bad for leaking memory. This can culminate in the web server eventually crashing due to running out of memory. Not what you want in a mission critical system. The MapGuide Server and the Web Server Extensions communicated over TCP/IP which I see as a natural boundary layer insulating the two from each other. It would be perfectly viable to port the Web Server Extensions to Java and .Net. The implementations would deserialize the C++ objects being sent over the wire into equivalent Java and .Net ones. This makes debugging easier, eliminates any native interaction altogether as well as making the library dependencies a bit simpler. As an added bonus is that having Java and .Net code which talks to the MapGuide server could be the foundation of a Java/JavaFX and/or Silverlight hight performance viewer. PHP implementations are available which run on top of both Java and .Net meaning PHP could still be supported that way. It is a brilliant plan if I do say so myself. The web server extensions consist of only about somewhere between 100 to 150 source files many of which are just interfaces. It is not a trivial project but perfectly possible none the less. The idea to port the Web Server Extensions was rejected for fear that porting the extensions would be too much work and maintaining two different implementations would be too much work as well as there being a risk of fragmentation between the platforms. I sympathise with this to a point but think some motivation may be that the community is mainly hardcore C++ types and they would much rather keep all the meaningful development in C++ where they can control it. I am not sure if fragmentation is as much as an issue given I don't see for example that a Java developer cares if the API is exactly the same for Java as it is for .Net. As long as the Java API remains compatible with future versions that is all a typical Java or .Net developer is really bothered about (and some things do break between versions on the MapGuide platform as it is). MapGuide could give ESRI a real run for their money as MapGuide delivers much of what ESRI does at a fraction of the cost. However none of this is any use until it could be made stable and scalable. Part of me would like to port the Web Server Extensions just to make a point that it can be done as well as demonstrating the power of a JavaFX viewer. Is would be a lot of work though and I am afraid if I did it there is a real risk that Autodesk / the Open GIS community around MapGuide would just turn up their noses because it isn't native C++. It is not worth putting in that kind of work for that to happen. It does kind of bother me though having worked on the problem so long, not to be able to see it through to conclusion. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
