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

Jackie Ng jumpinjackie at gmail.com
Sun Dec 27 01:35:42 EST 2009 

Just another guy with no oar in the water :-)

I am in favour of whichever solution/technologies that allows the viewer to
operate in a *disconnected/offline* scenario. I believe that this will open
up a whole bunch of scenarios that were previously not possible with
MapGuide in its current form.

Also I think that we shouldn't stress too much about IE6 support. If they
want to still live in 2001 and not move with the times, they can always
stick with the basic AJAX viewer :-P

- Jackie


Carsten Hess wrote:
> 
> 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
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> 
> 

-- 
View this message in context: http://n2.nabble.com/Future-Development-Options-for-Web-Server-Extensions-and-new-High-Performance-Viewer-tp4208470p4219854.html
Sent from the MapGuide Internals mailing list archive at Nabble.com.

More information about the mapguide-internals mailing list