[mapguide-users] Differences between PUBLISHED_API and INTERNAL_API

[Benoit Bégin]

Hi,

So I've decided to dust off my C++ skills and did a bit of a deeper dive into the FastCgi / HttpHandler for Mapguide. I'm trying to find new, more efficient ways to develop applications with Mapguide and making it a part of more complex systems, such as having a gRPC interface. I'm looking into using .NET Core with version 8 of the framework. I believe there's a lot of cool stuff we could make Mapguide do, but I am hitting a bit of a performance wall on some functionalities, primarily with map draws.

The biggest challenge I'm encountering is that it appears some functionalities are hidden away behind the INTERNAL_API flag, that I believe just hides them from SWIG, but they still get rolled up in the C++ binaries. I did a quick check on MgPlatformBase.dll and you do get functions like MgMapBase::SetViewCenter and MgMapBase::SetViewScale. Both of these calls are used by the mapagent.fcgi whenever you're doing a GetDynamicMapOverlayImage.

There's a few more of those functions that gets hidden away like that and I feel it makes hitting better performance harder when trying to use the exposed APIs. It also makes some functionalities impossible to do, such as just drawing an image with the current map selection.

In keeping with my GetDynamicMapOverlayImage, if you want to do the same in C#, you need to use RenderMap method on the MgRenderingService with all the exposed options, versus duplicating what the FastCgi is doing and calling up RenderDynamicOverlay. We just can't do the same in C# and it does appear to cost 30% of performance. This is napkin benchmaking notes, I'd love to get more concrete numbers but it's difficult when comparing apples and oranges.

So my question is, is there an historical reasoning behind hiding away those APIs? It feels more like an Autodesk thing than an API design thing. Although I will admit I might be missing the reason to hide away SetViewCenter. Maybe it's to prevent devs from shooting themselves in the foot.

Would having a "use at your own risk" version of the API with no hidden away to C#, Java and PHP methods be something useful for the community? With all the work Jackie put in moving to a standard version of SWIG in 4.0, maybe it's even something someone with basic knowledge of C++ like myself could get done?

Cheers,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapguide-users/attachments/20240418/64ac04ba/attachment.htm>