[mapguide-internals] MGOS/MGE Compatibility issues: Resource
Service opcode mismatch.
jason at jasonbirch.com
Wed Mar 17 13:23:18 EDT 2010
As an aside...
Just saw today that IE9 will have native SVG support. Very cool! Perhaps
an HTML5 Viewer for MapGuide isn't as far down the adoption curve as I
thought it would be. Only real problem is that IE9 isn't going to be
supported on XP...
Jackie, is the going to be inhouse-only code for this customer, or is there
a chance that it could be rolled into the MapGuide trunk? PDF and SVG
support would be incredibly cool.
Adding SVG as a WMS output format would be very cool too.
On 16 March 2010 02:37, Jackie Ng wrote:
> 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
> 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
> 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
> 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
> 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
> 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
> to a closed source MGE server actually feasible? To get where I currently
> 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
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
More information about the mapguide-internals