[mapguide-internals] Bounderies between mapguide Server and Clients

[Carl Jokl]

Thank you for the responses. It has certainly given me a better idea of how
things work.

As regards the memory leak issue. This was an issue at one stage. If this
has been addressed then it isn't so much of an issue. The reason I brought
it up is that at one point the memory leak we encountered was such that it
was building up significant amounts of memory when doing heavy manipulation
of large feature sets. The worrying aspect was that I tried maticulously
disposing of every MapGuide object involved as soon as it was no longer
needed and by measuring the footprint of memory before and after it didn't
make any difference at all. The danger is that with a significant memory
leak the IIS Asp.Net process will eventually run out of memory and crash.
End result is the web application crashes and we have an angry client. By
comparrison any slight snags caused by random garbage collection are not
much of an issue in comparrison. I know it doesn't have to be either or. If
there is no memory leak then none of this is an issue anyway. It was just
frustrating in that instance to feel like there was nothing we could do from
the .Net API to free up that memory. 

I don't know that the slight snag in performance when garbage collection
runs would be so visible on mapguide and has been more of an issue when it
comes to real time applications running some kind of smooth animation. The
performance of the VM based platforms continues to improve but I suppose
this is less of a core issue anyway for us. The issue is that if it does
come to having to delve into the source code to solve issues. The common
language for the whole development force is C# .Net. We have some
individuals who can code C++ but that severly limits who could look into the
problems and the risk that the few that could may be too busy on other work
and not free to look into problems.

I agree that fragmentation could occur. As it is trying to interoperate
different technologies is going to cause some issues. There are advantages
and dissadvantages of different approaches. Architecturally it seems to me
in theory at least that trying to keep the web component layer and the
actuall map guide server as loosly coupled as possible is desirable. That
would be the case even if it were only C++ talking to C++ without any other
languages in the equation. There is the "Open-Close" principle of making the
API open to extension but closed to modification. The API stands as a
contract to the client that is not supposed to change. It the situation is
such that each new version of MapGuide is going to break the API that could
be seen as a problem in itself. If the bridge between the two layers is
stable and consistent then it means existing functionality will continue to
work as expected even with new versions of MapGuide.

I could go on but the bottom line for us is that we just want to be able to
do with MapGuide Enterprise what we have been able to do with MapGuide 6.5.
This has continued to prove illusive. Even when functionality is available
we often find issues with performance or stability. 

Anyway thank you for all the responces, it has given me a better
understanding of the architecture.

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