[mapguide-internals] Future Development Options for Web Server Extensions and new High Performance Viewer

[UV]

interesting proposal.
could you clarify a bit more on the issues with the swig based interface?

so far you mentioned

1. possible memory leaks
2. difficulties observing internal state
3. linking issues

Is that enough to warrant this extensive work on multiple API flavors?
Most of the mentioned issues could be addressed with improved 
documentation and examples.
And being able to observe the complete internal state of mapguide 
objects seems quite a high expectation
and partial observation shoul be possible as is.

So far the benefits of replacing the SWIG Api with some extensive manual 
work is poorly motivated as the java plugin could connect also to the 
swig api.
Generally using a web server in the middle tier is a common 
architectural design which opens up further scalability options.
Simplifying the system design by eliminating the web tier in the middle 
might have some benefits,  but we should be very clear about those 
benefits.

Maybe you can clarify on the expected benefits a bit more?


carlj wrote:
> Having worked quite extensively with MapGuide for the past 2 years I was
> hoping to get a discussion going regarding trying to address some of the
> pain points of MapGuide Enterprise / Open Source.
>
> Many organisations have had difficulty migrating from MapGuide 6.5 to
> enterprise due to difficulties with stability and performance. Rather than
> pointing fingers I hope to have a professional discussion of the options for
> addressing some of the issues.
>
> One pain point is the MapGuide web server extensions. These are implemented
> in native C++ and access to the development platforms such as .Net, Java and
> PHP. This is done using SWIG to auto-generate objects in the platforms using
> them. 
>
> I want to propose that the use of SWIG should be gradually phased out in
> favour of implementing the Web Server extensions in as pure .Net and Java
> etc. I had originally discussed trying to port the web server extensions in
> their entirety in one go but due to the volume of work involved this could
> take a long time. This may still be a long term goal but in the shorter term
> converting such things as the value objects and the core communication /
> serialization components would be a good starting point. 
>
> There is likely to be resistance to the suggestion of porting as there is
> the disadvantage of having to duplicate changes across multiple
> implementations. I personally believe that in the long run moving towards
> the webserver extensions being implemented in the specific platform of the
> website will beneficial in the future. SWIG is known to leak memory if not
> used very carefully. Also many developers encounter lot of pain due to not
> being able to observe the internal state of the objects with which their
> applications interact. Dealing with the library dependencies also causes
> pain.
>
> As the Web Server Extensions communicate with the server via TCP/IP then
> this seems to me to be a natural application boundary between the MapGuide
> server and the Web Server Extensions. All the platforms currently supported
> by the web server extensions are able to communicate using TCP/IP. 
>
> There is an added bonus to having Web Server Extensions code ported to Java
> and .Net and this is that it could be used as the basis of a new plug-in
> based MapGuide viewer to fill the hole left by the unsupported DWF viewer.
> The new viewer could be higher performance than even the DWF viewer was able
> to be because rather than rendering DWF (meaning the server has to first
> package up data as DWF) a new viewer would instead be able to use the ported
> Web Server Extensions to directly de-serialize the C++ objects into objects
> in Java or .Net. These could then be used to render the map purely on the
> client. With all the rendering pushed to the client, the server has much
> less load and the overall solution should scale better. As an added bonus
> these technologies also offer the possibility of, for the first time,
> rendering 3D mapping data in the browser on the client. 
>
> For situations where this viewer would not work the AJAX viewer is still
> going to be available. I do not believe that the AJAX viewer could ever be
> expected to achieve the performance possible with a plug-in based viewer.
>
> I have already had a discussion about this idea off-line but the suggestion
> was to create another C++ based browser plug-in. I am not in favour of using
> C++ for a browser plug-in as this would likely mean going back to supporting
> one browser on one operating system which goes against why an organisation
> would be pushing an application into the web. When using native C++ on the
> client then it might as well be a full client application rather than a web
> based one. Granted the Viewer API allows some customization via JavaScript
> but I would much rather use a plug-in technology which is cross platform and
> cross platform. I would favour this even if the performance were somewhat
> less than possible in native C++.
>
> There are more points that I could make but I think I would leave it there
> for starting a discussion.
>  
>