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

Wed Dec 23 09:22:33 EST 2009

a few thoughts

aren't stability & performance are more core server issues than the
web front end stuff

The future of the web is Javascript, rather than the whole re-invent the wheel
approach, why not flesh out the ajax api. I shouldn't need to write
php/.net/java
server side code to be able to render a simple map.

Aren't most of the issues with MG a lot of the time FDO related? dead
& unclosed connections

Fixing the basic issues with SDF and SHP providers which cause us to
ship with connection
pooling disabled in the standard config, it a performance killer

Is it possible to abort requests if the http connnection is dropped?
Zooming in on
a slow map can DOS a mapguide server so easily

Being able to simply shutdown the server without waiting for things to
finish would
really make a huge difference as well.

Fix core issues before tackling the other stuff

2009/12/24 Jackie Ng <jumpinjackie at gmail.com>:
>
> 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.
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>

-- 
Zac Spitzer
Solution Architect / Director
Ennoble Consultancy Australia
http://www.ennoble.com.au
http://zacster.blogspot.com
+61 405 847 168