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

[Jackie Ng]

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