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

[Jackie Ng]

Your ideas sound great in theory, but it how they will be applied in practice
that will be the real deciding issue.

My main concern is the effort involved in having to develop and *maintain*
the Web Server Extensions for <language of your choice> "by hand". Take the
effort required to develop one WSE in .net and multiply it by 3 (for PHP and
Java, assuming we still want to support these 3 platforms). 

There is also the high possibility of implementation-specific bugs and
issues cropping up. At least SWIG sorts of provides a level playing field in
this respect (memory leaks aside, all 3 language bindings are
logically/functionally equivalent). 

The developer effort to do this would be monumental. It just sounds
infeasible from a resourcing standpoint. I doubt you'll see much investment
from Autodesk on such a developer effort. Currently I can only see this
working as an "out-of-band" project.

And all this for (what I presume to be) a high-performance viewer? Could we
not look at this from another angle? 

How about extending the mapagent http interface to support the capabilities
required by a high-performance client viewer? Or is the mapagent (or doing
things over http) just not performant enough?

On another (slightly unrelated) note, one of the "unique" uses I've seen
with MapGuide 6.5 was the ability to create "fat" static MWF files such that
the MapGuide 6.5 ActiveX viewer can function as (or part of) an offline
disconnected client viewer application.

Would your proposed ideas enable such a use case in MapGuide Enterprise /
Open Source?

- Jackie


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.
>  
> 

-- 
View this message in context: http://n2.nabble.com/Future-Development-Options-for-Web-Server-Extensions-and-new-High-Performance-Viewer-tp4208470p4208712.html
Sent from the MapGuide Internals mailing list archive at Nabble.com.