[mapguide-users] HTML5 client-side viewer (Was re: Re-thinking Fusion redlining efficiency)

[Jackie Ng]

Oh are we going to have another client-side vector viewer discussion? :)

Since our last discussion on this subject:

 * Silverlight has been EOLed by Microsoft
 * Java applets are security swiss cheese under Oracle's stewardship
 * Flash is in terminal decline.
 * HTML5 capabilities has been growing in leaps in bounds with near
unanimous support from all modern browsers for the subset of HTML5 features
that we would want to utilise for building a client-side vector map viwer.

So yes, HTML5 is indeed the logical choice. But past discussions on this
have failed to add some real meat that would allow someone to start playing
around with the discussed ideas.

If we just want a client-side vector viewer with basic styling options, then
I'd just let OpenLayers 3.0/Leaflet/etc solve the problem for us and
re-focus our efforts on how we can deliver this data to them in the most
efficient manner. 

 * I wouldn't suggest WFS in its current form as the current WFS
implementation in MapGuide leaves a lot to be desired in terms of memory
efficiency. It has the same problem as SELECTFEATURES and friends have
pre-RFC130, the responses are not truly streamed out but fully buffered
internally. Not very efficient if you want to scale out to multiple users.
 * GeoRest integration is a bit difficult as its configuration aspect falls
outside of the MapGuide resource service. The repository is after all where
all our configuration stuff is stored, so we should be leveraging this and
not have this information lying out in the external filesystem. This would
involve lots of discussions and thoughts about introducing new resource
types and matching XML schemas to go with it.
 * You talk about vector tiles, could you possibly elaborate on this? Is
this stuff cacheable server-side like its image-based counterparts?

I would prefer something that allows us to re-use our existing Layer
Definitions for client-side vector rendering. I'm not sure whether
ol3/leaflet support customizable rendering pipelines where we can take over
certain aspects of the rendering process and plug our own method of
rendering features in.

I toyed around with a truly "out there" idea of adding a SDL-based
SE_Renderer and then using emscripten to "transpile" the
rendering/stylization core with the SDL renderer to javascript, where the
SDL API calls get translated to HTML5 canvas calls. This "transpiled" core
could then theoretically be enough to build a client-side rendering service
around with an actual viewer on top. But this idea was scuppered when I
found out that the stylization library had a tight dependency on FDO and its
expression engine. I might revisit this idea when I can find out how to
refactor out this FDO dependency.

I too would like a client-side vector viewer. All our viewer technologies
thus far are nothing more than glorified LiteView clients, we do need the
modern contemporary to the ActiveX viewer.

But like I said we really need some discussions with meat in them. All
previous discussions have been somewhat fruitless.

- Jackie



--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Re-thinking-Fusion-redlining-efficiency-tp5065272p5065968.html
Sent from the MapGuide Users mailing list archive at Nabble.com.