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

[Jason Birch]

There is definitely potential either was, and perhaps a hybrid
solution will turn out to be best; choosing to render inactive layers
as raster, and active, editable layers as vector.

Anyway, not much point in imagining, especially since I don't have a
enough time in on this stuff to have a good gut feel for what the
right balance will be. I do think that advances like opening the gpu
up to browsers, etc, will mean that there will be lots of potential
for experimentation, and that using the web outside a browser alsdo
has strong potential...

Jason

On 2009-12-26, Carsten Hess <carsten.hess at autodesk.com> 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
>