[mapguide-internals] RE: MGOS/MGE Compatibility issues: Resource Service opcode mismatch.

[Trevor Wekel]

Hi Jackie,

Yes.  The adsk 2.1 sandbox is used to build MGE2010.  However, there are additional pieces added which are not included in Subversion.  Furthermore, adsk 2.1 contains many different revisions of code.  It is impossible to tell which specific revision corresponds to releases of MGE.

MGE and MGOS compatibility is another issue.  I expect that the web extensions APIs and the HTTP operations are currently the only "compatible"  APIs between MGE2010 and MGOS 2.1.  As far as I know, the PSC has never discussed binary compatibility within the server code base.

Unless you are building against the correct version of the code, it will be difficult to ensure that internal binaries are 100% compatible.  For example, adding a single method to a C++ class will change the vtable for the class.  If the class headers are not the same, you will end up calling a different method.

It may be possible to rectify this situation in future releases by syncing the releases of MGOS to MGE and building them off the same code base.  However, without dedicated (paid) resources to maintain the open source builds and installers this will not be easy.  I believe it is unreasonable to force a project schedule upon people who donate their time.

Having said all this, it seems to me that SVG and PDF support are excellent features that should be rolled into the core server.  If possible, I would develop against MGOS and get the code checked into Subversion.  That way, it will be included in MGE and MGOS in a future release.

Third party extensions to the core server are definitely a good thing.  I just don't think we have considered the ramifications of supporting them yet.  It is problematic.  These extensions would be developed as part of a contract but would only be included in the binaries at a "later date" as determined by release schedules.  This delay may not be acceptable for the contract.

Regards,
Trevor


From: Jackie Ng [mailto:jumpinjackie at gmail.com]
Sent: March 16, 2010 3:38 AM
To: mapguide-internals at lists.osgeo.org
Cc: Jason Birch; Zac Spitzer; Trevor Wekel; haris at sl-king.com; traian.stanev at autodesk.com; bruce.dechant at autodesk.com
Subject: MGOS/MGE Compatibility issues: Resource Service opcode mismatch.

Hi All,

This is a bit of a hardcore question here...

I have been working on a custom native SE_Renderer for use by one of our clients who we have scoped to use MGE2010. This SE_Renderer uses cairo (http://www.cairographics.org) to produce SVG and PDF files natively from a MG runtime map instance. SVG file support is a major requirement of our client, and PDF file support was just a positive consequence of using the cairo rendering library.

I'm using the MGOS adsk 2.1 sandbox to build this custom renderer on the assumption it is API compatible with MGE2010, such that I can drop in the MGE2010 dlls when it comes to using our custom renderer in MGE2010

One of the things I'm currently trying to implement is the rendering of symbology from W2D Symbol Libraries, and here is where I am getting into a pickle.

Management of symbols (RS_SymbolManager) requires using the MgResourceService to grab the actual DWF content. The problem I am experiencing is that certain APIs in MgResourceService (actually the proxy resource service), are firing off the wrong opcodes to the MGE server.

For example, if I call MgResourceService::GetResourceData() the MGE server is actually calling MgResourceService::EnumerateResourceData() (as indicated in access.log)

To test whether the opcodes are being offset by a constant number, I tried calling MgResourceService::EnumerateResourceData(), the MGE server actually calls MgResourceService::GetRepositoryContent() (as indicated in access.log). The two tests revealed that the offset was not by a constant value, so that theory went to the bin.

I tested the GetResourceData() call against an MGOS server (built from the same adsk 2.1 sandbox) and the MGOS server calls the correct API, as you would have assumed.

I find this strange because the opcode definitions are in MgPlatformBase.dll, and I am using the version of MgPlatformBase.dll that corresponds to the version of the server I am talking to. It's not as though I'm using a MGOS dll to talk to a MGE server. The MGE server is getting the wrong opcodes sent from its own dll (???)

Could it be a compiler issue? I'm aware that STL strings are affected by some compiler settings, but these opcodes are enums. Surely they can't be sensitive to compiler settings!

In a nutshell: I can't render symbology for a MGE map, because I can't fetch the symbol content from a MGE server. I can't fetch the symbol content because the proxy resource service is firing off the wrong opcode to the MGE server, resulting in an incorrect API call. That proxy resource service is from the same MGE installation.

Any ideas?

On a somewhat related note, is the concept of using open source MGOS to talk to a closed source MGE server actually feasible? To get where I currently am with this custom renderer so far is an achievement in itself! But I am somewhat disheartened with subtle issues like this. Maybe I'm going about this in the wrong way?

- Jackie


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