[mapguide-internals] Bounderies between mapguide Server and Clients

[Carl Jokl]

I want to ask an architectural question regarding the implementation of
MapGuide to see if I understand the structure from that perspective.

I note that it seems that MapGuide at the server side listens on three ports
(2800, 2801, 2802). Is there then a clean boundery between the client and
server components of mapguide? I.e. is the interaction between the MapGuide
API classes and the server utimately come down to communication over TCP/IP?

If this is the case then my next observation would be that in many cases the
classes in .Net (and I would suspect also Java too but have not inspected
these closely to be sure) tend to be little more than thin wrappers around
native C++ objects. 

If this is the case I might question whether it would not be beneficial to
remove the dependency of the Classes in .Net and Java for the client side on
any native C++ mapguide components. Both of these platforms have the ability
to communicate over TCP/IP with a mapguide server without needing to rely on
any native code (outside of that which is part of their native platforms). 

I could see a potential reason why wrappers have been used. I suspect that
the Autodesk team is most comfortable in C++. Secondly this approach means a
fix in one place on the client serves to provide a fix for all platforms
where otherwise the fix would have to be applied for each language
implementation of the client.

With that advantage taken into consideration I would still think that in the
long run it would be more beneficial to have clients written in pure .Net
and pure Java with no native dependencies. TCP/IP would provide the
insulation / bounderies between the different platforms. 

The advantages of doing things this way are: Memory leaks are likely to be
far less of an issue given both .Net and Java have automatic memory
management. This puts more power also into the hands of the developers using
the respective api as all the client memory is under their control where
otherwise the native unmanaged memory is beyond thier control. Secondly in
terms of distribution of libraries it provides potential to compile down to
a single .Net assebly or Java Archive. This makes for cleaner and more
flexible deployment as no thought needs to be taken about any native
dependencies the libraries may have as is the case presently. Thirdly
performance as the bridge between managed and unmanaged code has some
overhead. How significant the overhead is in this case I cannot say but it
is known that every time data has to pass back and fourth between the
managed and unmanaged layer there is some overhead involved it allowing this
to happen. Fourth, both .Net and Java are amed to be Write one run anywhere
systems whereby once a library is compliled the same library should be
usable without recompilation on any supporting platform. When native
dependencies are invloved the native components have to be recompiled for
each platform on which the library is to be used. Fifth, in terms of the
open source version of mapgude having pure .Net and pure Java
implementations of the client libraries allows for leveraging the two
respective communities developers to improve and maintain the code. At
present only really C++ developers are able to make a real contribution to
the project.

Thoughts?

Carl Jokl

-- 
View this message in context: http://n2.nabble.com/Bounderies-between-mapguide-Server-and-Clients-tp2357804p2357804.html
Sent from the MapGuide Internals mailing list archive at Nabble.com.