[mapguide-internals] Re: OpenLayers + SVG = MapGuide Vector Viewer
trevor_wekel at otxsystems.com
Fri Sep 17 09:22:05 EDT 2010
I do not believe this is a greenfield project. It leverages our existing software stack. We'd be using and building infrastructure around the currently available support for vector layers in OpenLayers. In fact, we may not touch anything to do with SVG. The OpenLayers project will (hopefully) handle SVG-on-IE9 for us. Here's some doc links for OpenLayers
This will definitely be an interesting "enhancement" project. And maintaining backward compatibility for existing clients will force us to think a little harder on how we implement it. A well thought out RFC detailing all the API changes will be required. We may have to break it into multiple RFCs for readability purposes:
JSON Transport of Features
Client based Selection and Properties display
OpenLayers based Vector Rendering and Stylization
Client based Layer Legend
(additional controls... Measure, markup, etc)
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: September 17, 2010 12:33 AM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] Re: OpenLayers + SVG = MapGuide Vector Viewer
I should be clear that I wasn't asking for IE6 support (given up on that a
long time ago) just to make allowances for IE8, the last XP browser. And
I'm not convinced that Opera support is a requirement either.
Perhaps I misunderstand the effort, but if SVG is just another layer type in
OpenLayers it sure doesn't seem like it would be easier to build another
custom viewing framework from scratch than to extend Fusion. We'll have to
support rasters anyway to display imagery in the SVG viewer.
Greenfield implementations are sexy and easier for developers to manage, but
are incredibly bad for implementers, their clients, and their end users.
Many of us are not in a position where we can realistically dictate to our
end users, especially not if it means ruling out computers that are only
three years old, or re-implementing our UI from scratch after only a year of
semi-stability. Massive change is almost always bad. I only sometimes agree
with Joel, but in this case he's dead right:
On 16 September 2010 14:24, Dave Wilson wrote:
> Actually IE6 is not included in the pretending :)
> Basically it allows IE8 to pretend to be IE7.
> Sadly given the nature of security issues today it's not reasonable to
> expect support for IE6. Unfortunately that means there is a lot of code out
> there that needs updating. It requires a lot of engineering to support 5
> common browsers (Opera, Chrome, Safari, IE and Firefox) and their legacy
> versions. Trying QA'ing 9 or 10 browser versions...that doesn't even include
> the code required to handle all the cases as generally one set of code does
> not behave the same in all browsers. It's not just a little bit of extra
> engineering effort. Given the time frame MG is developed in Enterprise vs OS
> you can't fault either side for having to cut things off. If we just
> "engineered it a little bit more" each time we'd never deliver anything.
> Old users will still have AJAX, but if you want the cool new stuff you have
> to upgrade. Consider online banking. If you don't use the browser the bank
> dictates you don't get to log on. It's that simple. Upgrading is a way of
> life. Unfortunately the history of browsers and html standards has created a
> large gap with IE6 that people and governments will have to deal with.
> Conceptually I like Trevor's breakdown in terms of supporting what you can
> given the browser version, but if customers want your service they will have
> to use what you dictate. Hopefully you don't do major upheavals like this
> often. The move to MGE was a big one after how many years? The deprecation
> of DWF was sad, but given it's platform specific and was another free tool
> that required a significant amount of resources to produce you can't fault
> Autodesk for cutting back in hard times just like everyone else. The fact
> you can even get MGOS is still huge.
> Just another point of view.
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
More information about the mapguide-internals