<div dir="ltr">You're mostly on the money. The purpose behind these various *_API markers is documented here and they're mainly for controlling what gets exposed to SWIG<br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div></div></div></div><div><br></div><div><a href="https://trac.osgeo.org/mapguide/browser/trunk/MgDev/Common/Foundation/FoundationDefs.h#L49">https://trac.osgeo.org/mapguide/browser/trunk/MgDev/Common/Foundation/FoundationDefs.h#L49</a><br></div><div><br></div><div>PUBLISHED_API and EXTERNAL_API members will be exposed to the managed API surface. Everything else will remain C++ public/private and inaccessible from managed bindings.</div><div><br></div><div>As to why certain methods are marked the way they are? Only Autodesk would know and I doubt you'll be able to get an answer from them now as to why.</div><div><br></div><div>Regarding your current problem. Have you looked at MgHttpRequest and MgHttpResponse classes? </div><div><br></div><div>Don't let the (horrible) name deceive you, for these are the same classes that drive all of the request handling in mapagent.fcgi meaning in your case you could provide a grpc interface with the same request parameters and call into the same code that the regular mapagent.fcgi handler would do.</div><div><br></div><div>It's probably better performance too (theoretically) as there are less managed <-> native call transitions involved and not having to new up a whole assortment of Mg* proxy classes to do things the non-mapagent way. Such intermediate objects (like MgMap) would be new-d on the native side and would be cleaned up automatically and deterministically on that same side, without GC from the managed side.</div><div></div><div><br></div><div>If you need .net reference code for how to use these classes, I have an ancient sample that demonstrates usages of MgHttpRequest and MgHttpResponse in a custom webforms .ashx handler (yes, that ancient!) </div><div><br></div><div><a href="https://github.com/jumpinjackie/mapagent-dotnet-sample/blob/master/MyCustomMapAgentHandler/mapagent.ashx.cs">https://github.com/jumpinjackie/mapagent-dotnet-sample/blob/master/MyCustomMapAgentHandler/mapagent.ashx.cs</a><br></div><div><br></div><div>But despite the ancient-ness, the usage of the classes in question can easily be transplanted to something more modern, like an <a href="http://asp.net">asp.net</a> core controller, or a GET/POST delegate handler for a minimal API or in your case, a grpc service implementation. The only difference in all of these transplant targets is simply:</div><div><ol><li>Figuring out how to set up the key/value collection of request parameters in the MgHttpRequest</li><li>Figuring out how to output the various types that a MgHttpResponse could return</li></ol></div><div><br></div><div>- Jackie</div><div><br></div><div>You wrote:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)">Hi,</div></div><div><div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)"><br></div></div><div><div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)">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.</div></div><div><div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)"><br></div></div><div><div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)">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.</div></div><div><div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)"><br></div></div><div><div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)">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.</div></div><div><div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)"><br></div></div><div><div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)">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.</div></div><div><div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)"><br></div></div><div><div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)">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.</div></div><div><div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)"><br></div></div><div><div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)">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?</div></div><div><div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)"><br></div></div><div><div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)">Cheers,</div></div><div><div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:11pt;color:rgb(0,0,0)">Ben</div></div></blockquote></div>