[mapguide-internals] Bounderies between mapguide Server and Clients

Trevor Wekel trevor.wekel at autodesk.com
Fri Feb 20 12:40:16 EST 2009


Hi Carl,

The serialization is custom but does follow a well defined format and there are child object in some cases.

Most of the heavy lifting - spatial select, stylization, rendering, etc - is performed by the Server.  We use GEOS for analysis operations like buffer.

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Carl Jokl
Sent: Friday, February 20, 2009 10:16 AM
To: mapguide-internals at lists.osgeo.org
Subject: Re: [mapguide-internals] Bounderies between mapguide Server and Clients


That answers the question.

I am curious on a couple of points raised though by the answer. The fact
that it seems Autodesk would not wish to change from the approach they
currently employ using wrappers is not so much of a surprise as I espected
that would probably be the case. Given the open source nature of mapguide
though it does not rule out the possibility of someone outside Autodesk
trying it out.

Even serialization isn't an absolute obstacle as long as the contents of the
classes is serialized in a consistent manner. In principle, if the binary
structure were consistent enough the object could be reconstructed at the
other end even in a different language. The data fields read out of a stream
item by item in sequence. I appreciate this soon becomes more complicated if
an object has child objects which were serialized with it.

Is the serialization which takes place within Mapuide custom written or
using another library? There are 130 classes used on the client but how many
of those need to be serialized?

I also wonder that in the case of some of these objects, there is likely to
be very little in the way of changes being made to them.

I personally (though this is just me) would not consider 130 classes to be a
massive number. I have internally written a toolkit for out companies
internal use in order to make development of mapguide easier more
straightforward. This project ended up consisting of 250+ source files
(virtually all written by myself). There seem to be quite a number of
MapGuide API objects which I have seen which seem to be kinds of value
objects.

On the question of GEOS this raises an interesting point. I thought that the
heavy geospacial calculation work was being done on the MapGuide server side
rather than the MapGuide API which I thought was really more of a front end
interface and which didn't contain much in the way of the business logic.
Perhaps that understanding was wrong.

Perhaps it would be best to delve more into the sourcecode. I am able to
program C++, just not as well as I program C# or Java.

In and ideal world I still like the idea of the self contained client and
server components.

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

_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals


More information about the mapguide-internals mailing list