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

Sat Dec 26 18:48:57 EST 2009

Jason,

I like that you go back to the use cases. Personally I agree that the server load is only a partial problem as hardware is cheap compared to software. Don't get me wrong, I think there is plenty that we as an overall community could do to make MapGuide more thread-able (have better multi-processor and multi-server support). I also believe that some rendering on the client is very intriguing as the clients have a lot of computing power to share that often lays dormant.

I think the second one use-case you talk (thick client for performance) is significantly more work compared to editing which I am happy to elaborate on. 

If you just do editing and assume a 100ms turnaround time for web-requests you can let the server do tons of simple operations (i.e. compute line patterns, compute snapping points, etc) for the client without recoding and loading all this data to the client. This comes to another interesting observation: In a web-environment we have to weigh network load against server-load for real benefit.

I think it would be very interesting to compare the data and packaging cost of vectors vs. rendered images. I bet we would find that feature wise dense maps, maps with lots of pattern / line styles, or raster layer and operations are more expensive to do on the server compared to do it on clients. At the same time they would be a lot cheaper on the network load if done on the server. I bet you would find the other extremes also to be true and find cases where sending the feature data over the wire would be more expensive on network and server compared to the rendering. Just think of a complex theming - the data would have to travel much further from the data-tier if you do client side rendering.

So in my opinion a mixed environment holds nirvana - and a lot of work - for both use cases! And then there is the stuff Traian hacks together that shows that simple solutions are not only fast but possible now compared to next year - nice work on that canvas based rendering Traian!

I also want to double your last comment. I don't have an oar in that water either. It is just something I have thought about a bit and want to share my thoughts on. Feel free to disregard :)

Cheers,
  Carsten

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Saturday, December 26, 2009 3:14 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] Future Development Options for Web Server Extensions and new High Performance Viewer

Carsten,

I see two different use cases. One, for a disconnected editor, where a
very thick client would be of great use. Two, for a slightly thicker
client for higher performance. Server load is, I suppose, somewhat of
a concern, but from my perspective isn't really critical... You can
always throw more hardware at a task :)

The first of these would require substantial re-implementation of the
mapguide interfaces ( or a non-direct port where mapguide is combines
with a bunch of other modules ) and has its own value proposition.

The second of these may be able to provide benefits from some changes
to the mapagent to output an optimized format for the client. Have a
look at the GeoREST sample that haris built using KML output to render
in openlayers. Its not perfect, but its a step in the right direction
I think. Basically GeoREST is rendering a vector format for
consumption by the client.

Finding the right balance of what to keep server side and what to
re-implement on the client may be difficult, but I think we could see
considerable benefit from looking at each layer.

Note, I like talking about this stuff, but don't have an oar in the
water on this particular item yet, so take what I say for what its
worth :)

Jason

Jason

On 2009-12-26, Carsten Hess <carsten.hess at autodesk.com> wrote:
> Ok, I tend to stay quite on this list but this is something of interest to
> me. I agree that client side rendering could help one aspect of the
> "scalability" of the server.
>
> So far the discussion has been all platform related but not talked about
> what the capabilities of such a client would be. Porting some of the code
> and API's would not be trivial to say the least. So I have my doubts that a
> heavy client would have the same "features" as MapGuide does today unless
> you can reuse code.
>
> As for platform, Traian quoted I think Stroustroup to me about a week having
> said "Java is not platform independent - Java is a platform". I totally
> agree with that whoever said it and I think flash is even more so a
> platform. Many small devices do support open web technologies like canvas
> and HTML5 but won't support Java or Flash. The most extreme example is the
> IPhone / Pod platform. Looking forward I believe that these devices will be
> more important than the intranet /internet / web-browser.
>
> Anyways, I think the real influence I would like to have on this discussion
> is to point out how much functionality there is on the server that would
> need to move or be given up / replaced.
>
> Cheers,
>   Carsten
>
>
>
> -----Original Message-----
> From: mapguide-internals-bounces at lists.osgeo.org
> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Zac Spitzer
> Sent: Thursday, December 24, 2009 7:56 PM
> To: MapGuide Internals Mail List
> Subject: Re: [mapguide-internals] Future Development Options for Web Server
> Extensions and new High Performance Viewer
>
> but openlayers is the defacto js api for geo spatial,
> and there are a lot more javascript developers than flash,
> plus it would 'just work' with our existing fusion client
> and also cool things like GeoExt
>
>
>
> 2009/12/25 Jason Birch <jason at jasonbirch.com>:
>> It may be more productive to contribute to OpenScales; it's based on
>> the OL idea, but in flash. It's not especially fast (I think its still
>> thinking mostly about rasters) but I think with the right contributors
>> it could be and duplication of effort / NiH sucks :)
>>
>> Jason
>>
>> On 2009-12-24, Zac Spitzer <zac.spitzer at gmail.com> wrote:
>>> I'd propose that what ever gets done, should be based on Openlayers
>>> as a dynamic layer. That way we can leverage everything else already done
>>> in OL. It also reduces the amount of work required by a factor of like
>>> 100,
>>> plus there's a lot more dev's around in OL land
>>>
>>> Plugins are rather 1990's, I agree with Jason that flash is a good
>>> option,
>>> but it i reckon it should just be a layer renderer which fits into the
>>> OL framework
>>> if at all possible....
>>>
>>> The possibilities with HTML5 Canvas are pretty cool...
>>>
>>> As for browser support, I would suggest, shock horror, we only target
>>> modern
>>> browsers, forget IE6 completely, and given the rumours about IE9
>>> supporting
>>> real world javascript peformance, perhaps ignore IE7 and even IE8, as
>>> neither
>>> supports Canvas
>>>
>>> that said, a flash layer for OL would avoid that problem :)
>>>
>>> 2009/12/25 Jason Birch <jason at jasonbirch.com>:
>>>> Oh, and I'm running on about 3 hours sleep in last 48, so sorry if that
>>>> was
>>>> overly cranky :)
>>>>
>>>> 2009/12/24 Jason Birch
>>>>
>>>>> I can't believe that custom ActiveX or Java are seriously being
>>>>> considered.
>>>>>  Is there no organisational memory of how much of a pain in the ass it
>>>>> was
>>>>> for customers to maintain multiple implementations of MapGuide just to
>>>>> make
>>>>> sure that everyone could use it?
>>>>>
>>>>>
>>>> _______________________________________________
>>>> 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
>>> _______________________________________________
>>> mapguide-internals mailing list
>>> mapguide-internals at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>>
>> _______________________________________________
>> 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
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals