[mapguide-users] Question on MapStudio OS (for Kenneth)

[Kenneth, GEOGRAF A/S]

I belive you need all dll files in the "bin" folder.
I choose another name for my managed API dll, so you may take all the dll's
from an installation and copy them into the bin/app folder of the 
executeable.

I would very much like a layer like the one used in MapStudio to be a 
part of the MapGuide API.
Unfortunately there are three languages that has to be supported.
So, unless someone writes and maintains an equivalent API for PHP and 
JSP, it can only be included as an add-on.

The main benefits of using the managed http layer, is that it can be 
made independant of the server version, and communicates on port 80.
This means that the program that is using the server, does not need to 
have any special port or setup, unlike the standard API.
The drawback, is that http is a bit slow, compared to direct 
communication with the server.

Regards, Kenneth, GEOGRAF A/S



Maksim Sestic skrev:
> Kenneth, thanks a lot for the clarification. Do you, by any chance, keep a
> list of unmanaged libraries used by MapGuideNativeAPI.dll in case it uses
> native MGOS connection object to connect to the server (DllImport-ed ones)?
> I'm just trying to keep the list short as much as possible :-)
>
> If certain MG-based FDO operations are not currently supported on
> HttpServerConnection level, I guess I'll have to get around MG and talk to
> managed FDO libraries directly, but this is a lesser problem.
>
> IMHO, MG community is currently aware of MapStudio OS as a counterpart of
> MapGuide Studio, but this managed layer underneath (MapGuideAPI.dll) is even
> more interesting. Both MGOS and MGE do lack usable managed layer, I hope
> someone (you?) will introduce a motion/RFC to adopt it as a standard
> supplement to both.
>
> Regards,
> Maksim Sestic
>
>
>
> Kenneth, GEOGRAF A/S wrote:
>   
>> The code for the MapGuideNativeAPI.dll is present in the sourcecode for 
>> MapStudioOS (look in MapGuideAPI/NativeAPIWrapper).
>> This code is generated with the MapGuide Open Source SWiG build, but I 
>> removed all .Net 2.0 stuff, and replaced it with .Net 1.1 counterparts.
>> Recently I have modified the generated code a bit, so that it will run 
>> on both 1.2 MapGuide dll's and 2.0 dll's.
>>
>> The MapGuideNativeAPI.dll is almost the same as the one distributed as 
>> MapGuideDotNetApi.dll (with the diffs mentioned above).
>> If you wish to use some of the more "advanced" stuff, where you can 
>> modify classes instead of Xml, you have to reference the MapGuideAPI.dll.
>> This DLL offers two connections to the MapGuide Server, namely 
>> HttpServerConnection and LocalNativeConnection.
>> The first one is 100% managed and does not use/need the Binaries shipped 
>> with MapGuide.
>> The second one uses the MapGuideNativeAPI.dll to access the MapGuide 
>> binaries (dll files), and connects with those.
>>
>> Both types of connection offers an identical set of methods to 
>> read/write MapGuide data as classes, rather than Xml.
>> Unfortunately the Http interface does not support all the features of 
>> the NativeAPI, so some features are only accessible
>> by calling that directly (missing methods are mainly related to FDO 
>> create/update).
>>
>> You can mix and match as you like, I see no problems in using both API 
>> models at the same time.
>> I have tested the code with both MGOS and MGE, I even have special code 
>> to handle MGE 2007 runtime maps :).
>> FYI, the HttpServerConnection is more extensively tested than the 
>> LocalNativeConnection.
>>
>> Regards, Kenneth, GEOGRAF A/S
>>
>>     
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide-users/attachments/20080216/d381ec52/attachment.html