[mapguide-internals] Bounderies between mapguide Server and Clients

[Tom Fukushima]

Hi Carl,

Trevor and Jason have already replied to your email.  But I wanted to reply to some of the points that you gave because I have my own point of view on those items. Note that these are just based on my experiences with .NET and Java projects that I've worked on.

I'm thinking that I shouldn't reply, because this could easily turn into a religious war about development platforms.....but against my better judgment I will anyway :)

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.
>>> I have found that in a system that needs to be responsive, automatic memory management gets in the way as the system will seemingly do major garbage collections at random times.  Garbage collectors are continually improving, but I have not been able to just leave things with the Garbage Collector in any major project that I have done.  When the call java.lang.Runtime.gc() (runs the garbage collector) becomes a NOOP, we probably there.
>>> There are still memory leaks and memory management issues that need to be considered.  If you maintain a cache, the objects in the cache can become garbage that is never collected. Java introduced weak references for this (e.g., java.util.WeakHashMap).
>>> I should say that the above may not be problems for the web tier because it is pretty thin, but I'm not sure.

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.
>>> Yes, this is true.  Is this important?  I know that it is important for web apps that need to download a single .jar file over a lot of .class files.  I don't see this as important for the web tier, but I could be missing something.

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.
>>> I'm not sure here, but I have consistently found that well written C++ performs better than .NET or Java. We'll only know for sure if someone does a comparison; but I suspect that we will find that any difference is small (I'm assuming here that we're not talking about the "thicker" parts of the API such as buffering or coordinate system conversions).

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.
>>> Yes, those are the claims.  I've have not found this to be true for any substantial program.

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.
>>> Actually, I think that the opposite will happen.  When a developer makes a contribution, they will need to know .NET, Java, PHP and perhaps other API languages that we start to support.  A developer or development team needs to do all of the work; they cannot change just one of the languages and then hope someone else will pick up the rest.


Again, I just want to emphasize that these are my opinions and what I have found.

Tom