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

[Jason Birch]

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.

Jason

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
> 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
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>