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

[Trevor Wekel]

Hi Carl,

First off, let me give kudos to Traian for developing a javascript based viewer which pulls tiled vector data.  I haven't done enough Fiddler digging yet see how the stylization rules are propagated.  Traian, have you had time to implement support for all of the MapGuide stylization rules yet?  This certainly an interesting and very impressive piece of work.

I do agree with Carl in that we have two schools of thought here.  Javascript/REST/HTML5 is the future of the web.  The web is a 3+ tier programmatic environment.  Business logic is implemented on an application server.  One of the advantages to this architecture is that deployment of applications is to a single application server and not a multitude of desktops.  MapGuide Open Source is currently a 3+ tier system.

Heavyweight clients are traditionally a two tier system.  Data is pulled from a database and the business logic is implemented on the heavyweight client.  Heavyweight clients are potentially more scalable and responsive since more processing is moved client side.  However, application deployment is much more onerous since applications have to be deployed to each desktop.  

Browser plugins attempt to marry both worlds.  MapGuide 6.5 falls into this category.  Business logic and data are pulled from a web server and the bulk of the processing occurs on the client.  I think Traian's viewer keeps rendering and interaction client side, maintains the existing programmatic API server side, and introduces a new client side REST API for a subset of the programmatic API.

Now onto your questions:

The rendering algorithms and routines are all open sourced.

As for the plugin technology, it may be possible to support both an ActiveX control and a java applet if the rendering stack is SWIG exported at appropriate boundary points.  Given that most of the MapGuide user base is proficient in .Net or Java and not C++, I believe the programmatic interface for the heavyweight viewer should be in .Net and/or Java.

Given unlimited resources, two plugin implementations would give our user base the choice of which language to use.  I have intentionally left PHP out of the discussion since I believe most heavyweight client development is now being done in .Net or Java.

I have not performed any investigation into exactly how this will all fit together.  Specifically, I have not mapped out how we transition from an ActiveX control to a .Net programmatic API.  Use Silverlight instead?  Maybe.  Will it support everything we need to do?  I don't know.

Java may be easier for a first implementation.  It runs everywhere and I suspect that the existing web extensions java packages will simply load into a java applet.  However, the web extensions service proxies are not HTTP compliant so this will not give us web connectivity out of the box.

Thanks,
Trevor



-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of carlj
Sent: December 24, 2009 2:21 AM
To: mapguide-internals at lists.osgeo.org
Subject: Re: [mapguide-internals] Future Development Options for Web Server Extensions and new High Performance Viewer


Lots of ideas and discussion.

There are two oposite schools of thought regarding rich content in the web.
I don't think different options need to be mutually exclusive. A more
powerful AJAX viewer is still a good improvement. 

The division on the web at the moment is those advocating pluginless
solutions using JavaScript and new features of HTML 5. I think the
improvements are welcome but one obstacle I see stands in the way. Internet
Explorer. There have long been many features which the web industry as a
whole has been trying to standardise on but Microsoft has dragged their
feet. In an ideal world where Internet Explorer was fully standards
compliant and kept up with the features of the other browsers things would
be different for my part. I don't care for Internet Explorer personally but
unfortunately it has the majority of the market share. It would be good if
either Internet Explorer catches up to the other browsers or looses enough
market share that it can be ignored. Unfortunately I don't count on much
likelyhood of either for the forseeable future.

The thing about using a plugin based solution is it is able to deliver a
very consistent experience across browsers and across platforms.

The one plugin technology with the widest adoption is Flash. I had a look at
Action Script but unlike Java and .Net there isn't a straightforward mapping
of all C/C++ primitive types. This isn't a brick wall by any means but where
Java or .Net could happily have enough low level control to deserialize
MapGuide classes from binary (taking into account endian missmatches
possibly) but I don't think Action Script was designed for that kind of
heavy programming control. The problem with Flash technology is that it has
been geared towards designers and so the scripting side has been dummed
down. As time goes on the programming capabilities are been beefed up and I
expect that to continue as it competes with JavaFX and Silverlight.

I would have to ask whether the rendering algorithms and rotines are covered
by the opensource or are proprietary to Autodesk?

Trevor, you are advocating using C++ but what kind of plugin technology are
you wanting to use to wrap it? Are you talking about another ActiveX
control? Are you talking about wrapping native code in a Java applet using
JNI?
-- 
View this message in context: http://n2.nabble.com/Future-Development-Options-for-Web-Server-Extensions-and-new-High-Performance-Viewer-tp4208470p4212529.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