[mapguide-internals] RE: MGOS/MGE Compatibility issues: Resource
Service opcode mismatch.
traian.stanev at autodesk.com
Tue Mar 16 11:12:35 EDT 2010
The RS_SymbolManager (and the SE_SymbolManager) do not require that you use the resource service. They are interfaces, one possible implementation of which is to use the Resource service directly. You can implement them in a different way that works (perhaps by doing an http request back to the server for the DWF... although that's a bit crazy, another way would be to load the dwf from its file location directly, etc).
About the binary compatibility issue - I don't know details about the differences between MGE and MGOS, but in general if you call one function but you get into another, it could mean that the vtable for the C++ class is different, i.e. the virtual functions compiled in the DLL or their ordering do not correspond to the ones you compiled with (as seen in your header file).
P.S. In case you ever need help with the SE_Renderer, I can answer questions about it in more detail.
From: Jackie Ng [mailto:jumpinjackie at gmail.com]
Sent: Tuesday, March 16, 2010 5:38 AM
To: mapguide-internals at lists.osgeo.org
Cc: Jason Birch; Zac Spitzer; Trevor Wekel; haris at sl-king.com; Traian Stanev; Bruce Dechant
Subject: MGOS/MGE Compatibility issues: Resource Service opcode mismatch.
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.
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?
More information about the mapguide-internals